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REVISION HISTORY 
Enhancements and Changes 



This revision reflects the software as of Version 2 of DECnet-20. The 
major enhancements and changes to the software include: 

• Increase in the maximum number of physical links supported for 
DECSYSTEMs-2040/2050/2060 to 8. 

• Addition of the network file transfer utility (all models) . 

• Support of up to 128K of memory in increments of 32K for the 
DN20 communications front end. 

• Provision for on-site generation of DECnet-20 for 
DECSYSTEMs-2040/2050/2060. 

• Provision for support of the KDP line controller (4-line 
synchronous DMA device) and the DN200 (remote job entry 
station) . 

• Extension of error and event logging capabilities to include 
hardware detected errors and CHK11 diagnostic messages. 

• Inclusion of additional features for the nonprivileged 
terminal user. 

• Addition of new commands and tools to provide a more 
maintainable product than Version 1. 

The contents of this revision supersede the entire contents of the 
DECnet-20 Version 1 manual. 



NOTES 

Chapters 1 through 5 in both the Version 
1 and the Version 2 manuals cover the 
same topics. 

Chapter 6 in the Version 2 manual 
describes "Running DECnet-20," which was 
described in Chapter 7 of the Version 1 
manual . 



IX 



Chapters 7 through 10 in the Version 2 
manual are new chapters and therefore 
have no counterparts in the Version 1 
manual. 

All changes from TOPS-20 Version 3A f 
DECnet-20 Version 1 are marked with 
change bars. Chapters 7 through 10 are 
marked with change bars in the Table of 
Contents only. 
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PREFACE 



This manual includes information about configuring, installing, 
programming, and operating DECnet-20. As such, it is directed to the 
following audience: 

• The application programmer responsible for writing the 
programs that will be exchanging data with programs on other 
systems in the network. This person should be an experienced 
MACRO programmer with some knowledge of network applications. 

• The system operator responsible for loading and starting the 
network software under the TOPS-20 monitor. This person 
should be experienced in TOPS-20 operations and be familiar 
with computer networks. 

• The system manager or system programmer responsible for 
installing the network software and generating the new system. 
This will probably be the person who installed the TOPS-20 
monitor . 

• The terminal user responsible for network tasks that do not 
require the enabling of capabilities. All timesharing users 
should be familiar with the TOPS-20 Command Language. 

This manual is also intended to be of use to field and corporate 
software service personnel engaged in the installation and support of 
the product. 

The manual is organized into five parts as follows: 

Part I, the Introduction, contains an overview of DECnet-20 and a 
discussion of system concepts, network options and network facilities. 

Part II, the Programmer's Guide, contains the programming facilities 
that the MACRO programmer must use in order to perform the following 
network functions: 

• Establishing a network connection using network-related 
monitor functions. 

• Transmitting and receiving both data and interrupt messages 
over a network link using standard TOPS-20 I/O monitor calls. 

• Terminating a network connection using network-related and 
standard monitor calls. 

• Controlling the network using network-related monitor 
functions. 



Part III, Operator's Guide, contains system loading procedures, 
DECnet-20 operator commands, recovery procedures, control procedures, 
and network-related error messages. These procedures include a number 
of examples printed in two colors for clarity. Terminal input is 
shown in red; system output is shown in black. 

Part IV, Terminal User's Guide, contains TOPS-20 commands available to 
nonprivileged users. All network-related TOPS-20 commands, including 
user-interaction with the file transfer utility (NFT) , are described. 
Examples are given in the form previously explained. 

Part V, Generating DECnet-20, discusses the concepts, features, terms, 
and commands that are related to on-site configuration of a DECnet-20 
system as well as the procedures for installing, verifying, and 
certifying the DECnet-20 system. 

Part VI contains the appendixes. 

The following are suggested guidelines for using this manual: 

• Application programmers should read Parts I and II, and the 
appendixes. 

• System operators should read Parts I and III, and the 
appendixes. 

• Terminal users should read Parts I and IV. 

• System managers and system programmers should read the entire 
manual . 

DECnet-20 runs under the TOPS-20 monitor on all the DECSYSTEM-20 
models. Both the application programmer's and the nonprivileged 
user's interface to DECnet-20 are the same regardless of the system 
model. However, there are differences in the installation and 
operation procedures between the DECSYSTEM-2020 and the other systems. 
Therefore, this manual uses the term DECSYSTEM-20 only when referring 
to all models. Specific systems are referred to by their model 
designations, such as DECSYSTEM-2020 or DECSYSTEM-2040, 2050, 2060. 

The following documents are either referenced in this manual or may 
prove useful in implementing DECnet-20 facilities. 

TOPS-20 Monitor Calls User's Guide DEC-20-OMUGA-A-D 

TOPS-20 Monitor Calls Reference Manual AA-4166D-TM 

TOPS-20 Software Installation Guide AA-4195G-TM 

TOPS-20 Operator's Guide AA-4176D-TM 

TOPS-20 Operator's Command Language 

Reference Manual AA-H600A-TM 

TOPS-20 Commands Reference Manual AA-5115B-TM 

TOPS-20 User's Guide AA-4179C-TM 



XII 



TOPS-10 and TOPS-20 Batch Reference 
Manual 

TOPS-10 and TOPS-20 SYSERR Manual 

TOPS-20 UETP Procedures/Reference 
Manual 

TOPS-20 System Manager's Guide 



AA-H374A-TK 
AA-D533A-TK 

AA-D606B-TM 
AA-4169F-TM 
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PART I 



INTRODUCTION 



CHAPTER 1 



SYSTEM OVERVIEW 



1.1 DECnet 

DECnet is the name given to the set of software products that extend 
the capabilities of various DIGITAL operating systems so that these 
systems can be interconnected to form computer networks. 

DECnet is based on sets of rules (protocols) known collectively as 
DIGITAL Network Architecture, or DNA. These protocols govern the 
execution of major network chores, such as transferring messages and 
data over physical lines, using error detection and retransmission to 
guarantee the integrity of data transfer, multiplexing multiple 
logical messages over a single physical connection, and controlling 
which nodes are allowed to communicate and when they can do so. 

Each operating system that supports DECnet implements some subset of 
the complete DNA. The subset of DNA that runs under TOPS-20 is called 
DECnet-20. 



1.2 DECnet-20 OPTIONS 

DECnet-20 task-to-task capability is required on all DECSYSTEM-20 
systems before an option can be added. Currently, 
DECSYSTEMs-2040/50/60 with a 128K DN20 communications front end 
support up to eight task-to-task lines. The DECSYSTEM-2020 supports 
two task-to-task lines. Task-to-task communication requires a minimum 
of one synchronous line. In addition to multiline support, the 
capabilities of DECnet-20 include the Network File Transfer (NFT) 
utility. 

One additional option is available for DECnet on the 2040/50/60 
systems : 

• RJE-20 Version 1. This option includes software for the DN200 
remote batch entry station and provides the facility for the 
DN200 software to be down-line loaded, diagnosed, and 
maintained remotely by the host system. 

A DECnet site may choose to divide the use of its lines between 
task-to-task and RJE. 

No options are available for the DECSYSTEM-2020. 
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1.3 DECnet-20 STRUCTURE 

DECnet-20 is a software product that extends the facilities of TOPS-20 
so that tasks running on any member of the DECSYSTEM-20 family of 
computers can communicate with other tasks in a computer network. 



When DECnet-20 
network softwar 
monitor and par 
handle network 
referred to as 
console front 
record peripher 
end through 
DECSYSTEM-2040, 
end. The major 



is running on a DECSYSTEM-2040, 2050, or 2060, the 
e resides partly in the main processor with the TOPS-20 
tly in a separate processor (the DN20) designed to 
communications functions. This latter processor is 
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end that controls the local command terminals and unit 
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a DTE hardware interface. Figure 1-1 shows a 

2050, 2060, a DTE, and a DN20 communications front 

protocol levels are also shown. 



When DECnet-20 is running on a DECSYSTEM-2020, the network software 

resides entirely in the main processor; there is no separate 

communications front end. Figure 1-2 shows a DECSYSTEM-2020 and the 
location of the major protocols. 

DECnet-20 has a multilayer structure; each layer, or level, 
corresponds to one or more protocols in the DIGITAL Network 
Architecture (DNA) . 

remote node 

n 

DECSYSTEM-2040, 2050 or 2060 



NETCON 



Operator 
task 



User 
task 



Monitor Call 
Interface 



TOPS-20 




JSYS 



• • • 



JSYS 



JSYS 



NSP 



DTE Driver 



modem 



DN20 



DTE 



Hard- 
ware 



Line 
driver 



DDCMP 



NSP 



DTE Driver 



Network 
Utilities 



MR-S-598-80 



Figure 1-1 DECnet-20 on a DECSYSTEM-2040, 2050, 2060 
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Figure 1-2 DECnet-20 on a DECSYSTEM-2020 



1.3.1 Hardware Level 

The lowest level of DNA protocol used in DECnet-20 is the hardware 
level. This level is implemented by line drivers that are tailored to 
the types and characteristics of the physical lines, modems, and modem 
control interfaces. The hardware level controls transmission 
techniques (synchronous or asynchronous, serial or parallel, full- or 
half -duplex) , character synchronization, and modem operation. In 
Figures 1-1 and 1-2, this level is represented by the line drivers. 



1.3.2 Physical Link Control Level 

The next higher level of DNA protocol is the physical link control 
level. This level is implemented by the Digital Data Communications 
Message Protocol (DDCMP) . DDCMP maintains control over the hardware 
level by using a 16-bit Cyclic Redundancy Check (CRC-16) to detect 
errors, retransmitting to correct errors, and numbering messages to 
ensure sequential data transfer. The next higher level of protocol, 
therefore, can be assured of a sequential and error-free data path. 

In Figure 1-1, the physical link control level is represented by the 
DDCMP layer in the DN20. The two DTE drivers, each in their 
respective CPUs, perform DDCMP-like functions to control the flow of 
NSP messages between the host computer and its communications front 
end . 

In Figure 1-2, the DECSYSTEM-2020 does not have a communications front 
end and therefore the DDCMP level is implemented entirely in the host 
computer . 
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1.3.3 Logical Link Control Level 

The next higher level of DNA protocol used in DECnet-20 is the logical 
link control level as defined by the Network Services Protocol (NSP) . 
NSP controls the flow of data between tasks in a network. This 
involves creating and terminating logical links (communications 
paths), multiplexing logical links into physical links, segmenting and 
collecting long messages, and ensuring end-to-end delivery of data in 
proper sequence. Logical links are described in detail in Chapter 2. 

When DECnet-20 is running on a DECSYSTEM-2040 , 2050, or 2060, the NSP 
protocol is implemented both in the TOPS-20 monitor running in the 
main processor and in the communications front end. In Figure 1-1, 
this level is represented by the NSP code in the main processor and in 
the DN20. When DECnet-20 is running on a DECSYSTEM-2020, the NSP 
protocol is implemented entirely in the main processor as shown in 
Figure 1-2. 

NSP in the main processor provides the TOPS-20 user with programmable 
access to the DECnet environment via the TOPS-20 file system monitor 
calls. NSP also resolves the byte-size differences between the 36-bit 
word structure of the main processor and the 8-bit byte structure 
required by the network. Additional NSP protocol and network 
utilities in the communications front end (or in the main processor in 
the case of the DECSYSTEM-2020) perform the bulk of the NSP control 
functions. 



1.3.4 User or Application Level 

DECnet and its first three levels of protocol (hardware, DDCMP, and 

NSP) provide for the exchange of data between network tasks. How 

these tasks interpret this data involves a user level of protocol. In 
both Figures 1-1 and 1-2, this user level is represented by the user 

tasks running on the DECSYSTEM-20. The user level of protocol is 
responsible for interpreting and acting on the data exchanged. 



1.4 DECnet-20 CAPABILITIES 

DECnet-20 provides the TOPS-20 user with basic network task-to-task 
capabilities. That is, local system or user tasks written in MACRO-20 
can exchange information with system or user tasks running in one or 
more adjacent nodes in a network. 

The local task accomplishes this by using the TOPS-20 file system 
monitor calls to open, read and write information, and close files 
using a pseudo-device representing the network. 

Below this user level, and transparent to the user, the network 
protocol takes over. NSP software running in the main processor (and 
in the communications front end when part of the system) manages the 
actual transfer of data over a logical link. User data is first 
reformatted into network-compatible segments and then transferred over 
the logical link. NSP also generates the appropriate control messages 
to open and close network connections. 
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A special network control task called NETCON is started at system 
initialization and runs under the system program SYSJOB. NETCON 
accepts operator commands (and command files) through the operator 
interface program ORION and the operator command parser OPR. Operator 
commands to NETCON will: 

• Down-line load network software into the communications front 
end of a DECSYSTEM-2040 , 2050, 2060. 

• Load network software into the synchronous line controller on 
the DECSYSTEM-2020. 

• Up-line dump the communications front end of a DECSYSTEM-2040 , 
2050, 2060 into a TOPS-20 file. 

• Dump the synchronous line controller on the DECSYSTEM-2020 
into a TOPS-20 file. 

• Log pertinent network load, dump, and line status information 
into the TOPS-20 SYSERR file. 



Display line statistics for any 
network. 



line on any node in the 



• Start and stop DECnet-20 lines on all DECSYSTEM-20 models. 

• Start a line in cable-loopback or controiier-ioopback mode 
(DECSYSTEM-2020) . 



Perform a loopback 
(DECSYSTEM-2040/50/60) . 



test 



on 



designated 



line 



Operator commands are described in Chapter 6. 



1.5 DECnet-20 PROGRAMMER INTERFACE 

Using DECnet-20, a MACRO programmer can transfer data between user 
storage and the network in much the same way that data is transferred 
between user storage and files on a peripheral device. The peripheral 
device, in this case, is the network; the file is a logical link. 
File system monitor calls, such as GTJFN, OPENF, and CLOSF, control 
the making and breaking of network connections. Input/output monitor 
calls, such as SIN, SINR, BIN, SIBE, SOUT, SOUTR, and BOUT, handle the 
movement of messages and data across the network logical links. 
Several network-specific functions have been added to the MTOPR 
monitor call to provide the user with some form of logical link 
management. These new functions are described in subsequent chapters. 



1.6 DECnet-20 OPERATOR INTERFACE 

Operator commands to the network control program, NETCON, fall into 
two classes: generic DECnet commands and TOPS-20-specif ic DECnet 
commands . 
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Generic DECnet commands function the same on all DECnet computer 
systems. These are the LOAD NODE and DUMP NODE commands to down-line 
load and up-line dump the communications front end, the SHOW QUEUE 
command to check the status of any queued NETCON requests, the SHOW 
COUNTS command to display line counter information, the SET EXECUTOR 
command to specify which node is to process subsequent commands, the 
SHOW STATUS commands, the SET STATE command, and the LOOP LINE command 
to loop a standard test message a specific number of times. 

TOPS-20-specif ic DECnet commands are extensions to the generic DECnet 
commands necessary for the implementation of DECnet under TOPS-20. On 
the DECSYSTEM-2040, 2050, and 2060, the SET NODE command establishes 
operating characteristics and the SET SECONDARY (TERTIARY) -LOAD-FILE 
command specifies the secondary (tertiary) bootstrap programs to be 
used for down-line loading the communications front end. On the 
DECSYSTEM-2020, the LOAD LINE and DUMP LINE commands load and dump the 
integral line controller. On all models, the INITIATE LOGGING, 
TERMINATE LOGGING, and SET LOGGING-INTERVAL commands control the 
recording of DECnet-20 line statistics. 



1.7 DECnet-20 TERMINAL USER'S INTERFACE 

As a terminal user (without OPERATOR or WHEEL privileges) , you use the 
TOPS-20 Command Language (EXEC) to communicate with the system. The 
TOPS-20 User's Guide and the TOPS-20 Commands Reference Manual 
describe the TOPS-20 Command Language in detail. 

Part IV of this manual describes EXEC commands that are specific to 
DECnet-20. It also includes Network File Transfer (NFT) . NFT may be 
used by the nonpr ivileged user. NFT gains access to the files and 
devices on other nodes through the Data Access Protocol (DAP) of the 
DNA, but this interaction is transparent to you. Your concern is the 
function and format of the NFT commands. 
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CHAPTER 2 
CONCEPTS AND FACILITIES 



2.1 SYSTEM CONCEPTS 

The basic concept of DECnet-20 is that the network is to be treated as 
just another TOPS-20 input/output device. TOPS-20 programs written to 
communicate with other tasks in the network use TOPS-20 file system 
monitor calls to request network functions. 

This concept is represented graphically in Figure 2-1. The local NSP 
code interfaces with the TOPS-20 monitor to provide the user with 
network access using many of the same monitor calls that are used to 
access local peripherals. Figure 2-1 shows this local NSP code 
residing in the main processor of a DECSYSTEM-2020. In a 
DECSYSTEM-2040, 2050, 2060, the NSP code resides in both the main 
processor and in the communications front end. The communications 
front end, if present, is transparent to both local and remote user 
tasks. 
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Figure 2-1 The Network as an I/O Device 



To initiate a dialogue with a target task, a source task identifies 
the target task as a file on the network device DCN:. The source task 
then proceeds to open the network file, write to it, read from it, and 
eventually close it, very much as if it were a file residing on a 
local auxiliary storage facility. 
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To declare itself as being available for a connection by a source 
task, a target task identifies itself as a file on the network device 
SRV:. When the SRV: file is opened, any incoming connect request 
addressed to this target task is forwarded to it by DECnet-20. The 
request may be accepted or rejected. If the request is accepted, the 
connection is made and data can be exchanged between the two tasks via 
reads and writes to the file. 

Other network concepts that will be used in subsequent chapters are 
physical and logical links, network job file numbers, network task 
identification, and network node identification. These concepts are 
introduced in the following subsections. 



2.1.1 Physical and Logical Links 

Physical and logical links are the basic elements of communications on 
a network. Physical links connect network nodes and logical links 
connect network tasks. 

A physical link connects two network nodes and can take one of several 
forms. In Figure 2-2, the physical link between nodes ABLE and ABLER 
is the DTE interface, a hardware device between a DECSYSTEM-2040 , 
2050, 2060 and its communications front end. The physical link 
between nodes ABLER and BAKER or between nodes BAKER and CHARLY can be 
a relatively permanent connection such as a leased or private 
telephone line or cable. It can also be a temporary connection such 
as a satellite link or radio circuit. 
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Figure 2-2 Logical and Physical Links 
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DECnet-20, running on a DECSYSTEM-2020 , supports two physical links to 
the network as shown at node BAKER in Figure 2-2. DECnet-20, running 
on a DECSYSTEM-2040, 2050, 2060, supports up to eight physical links. 
One physical link to the network is shown at node ABLER in Figure 2-2. 

A physical link can support one or more logical links. 

A logical link connects two network tasks. A logical link usually 
shares a physical link with other logical links. A logical link can 
span more than one physical link as shown from node ABLE to node BAKER 
in Figure 2-2. 

The simultaneous sharing of a physical link by multiple logical links 
is referred to as multiplexing. Among the functions of NSP in 
DECnet-20 are the mixing of outgoing logical link data from several 
users (multiplexing) for transmission over a physical link and the 
separating of incoming logical link data (demultiplexing) for 
distribution to individual users. 

In Figure 2-2, the logical links between users A and D, B and E, and C 
and F, are multiplexed and span two physical links: ABLE to ABLER and 
ABLER to BAKER. The logical link between users G and H is the only 
data path on the physical link from BAKER to CHARLY and therefore no 
multiplexing is necessary. 



2.1.2 Network Job File Number 

The network job file number in DECnet-20 is analogous to the job file 
number (JFN) assigned to all input and output files being processed by 
TOPS-20 tasks. In the TOPS-20 file system, a JFN is associated with a 
file specification. In DECnet-20, where the network is treated as an 
input/output device, a network JFN is associated with a specification 
for a logical link, the network equivalent for a file. 

The same monitor call (GTJFN) is used to obtain either a network or a 
file JFN. The information passed to the GTJFN monitor call for a 
network JFN is similar in format to that supplied for a file JFN. The 
format and usage of logical link specifications are explained in 
Chapter 3, Establishing a Network Connection. 



2.1.3 Network Task Identification 

A network task is any program that is engaged in, or intends to engage 
in, a network dialogue. Network tasks in DECnet-20 can have two 
distinct identities: a generic task identification and a unique task 
name . 

The generic task identification is used to address a network task that 
provides a class of service to other network tasks (for example, a 
network utility program) . Multiple copies of such a network program 
can be loaded, started, and identified by class of service. Other 
network tasks can then request this service by specifying a connection 
by generic identification. This guarantees a connection to one of the 
available copies all of which are assumed to provide the same service. 
The generic task identification consists of two parts: a one-byte 
object type (numeric) and an optional object descriptor 
(alphanumer ic) . 
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Object types 1 through 127 are reserved for DECnet utilities and 
control programs. Object types 128 through 255 are available for 
user-written installation-dependent network utilities. Object type 
is reserved for addressing tasks by their unique task name. Appendix 
B contains the current list of DECnet object types. 

The use of object descriptors is dependent upon the implementation of 
NSP on the remote node. If the remote node is running a system other 
than TOPS-20 DECnet-20, read the DECnet manuals for the system being 
used. In DECnet-20, object descriptors can be used with object types 
128 through 255 if so designed into the user program. 

A unique task name, on the other hand, is used to address a specific 
network task. Only one copy of such a task can be running at any one 
time on any one node. If a network task is identified by task name 
alone, it must be addressed by the special object type and a 
descriptor that corresponds to the unique task name. 



2.1.4 Network Node Identification 

Each node in a network is identified by a unique node name and a 
unique node number. The node name must be one to six alphanumeric 
characters; the node number must be a positive integer between 2 and 
127, inclusive. When DECnet-20 is installed on a DECSYSTEM-2040, 
2050, 2060, the main processor and the DN20 communications front end 
are each considered separate network nodes. Each, therefore, must 
have a unique name and number. 

Whenever a source task requests a connection to a target task, the 
source task must supply the local NSP with the name of the target 
node. The local NSP uses this node name to generate the destination 
address of the NSP message that requests a connection to the target 
task. Sending this request for connection to a target task is the 
first step in establishing a logical link. 

During the installation procedures for DECSYSTEM-2040/2050/2060, the 
main processor (host) is given an identifying name and octal number. 
During on-site configuration, as part of the NETGEN procedure, the 
DN20 and the DN200, if present, are given node names and numbers. 
Within the same network, all identifying names and numbers must be 
unique. See Chapters 9 and 10 for the procedures for assigning node 
names and node numbers. 



2.2 NETWORK FACILITIES 

The TOPS-20 programmer can implement the task-to-task function of 
DECnet-20 using MACRO programs or subroutines. Specifically, a subset 
of the TOPS-20 file system monitor calls acts as the interface between 
the programmer and DECnet-20. These network-related monitor calls 
allow the MACRO programmer to: 

• Declare a network task as willing to accept connections. 

• Initiate a request for a connection to another network task. 
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Accept or reject a request for 
network task. 



a connection from another 



Transmit data to and receive data from another network task. 

Interrogate the status of a logical link. 

Retrieve the connect attributes of a network task. 

Exchange high priority interrupt messages (up to 16 bytes in 
length) with other network tasks. 

Disconnect a network connection. 

The network-related monitor calls and their functions are listed in 
Tables 2-1, 2-2, 2-3, and 2-4. Many of these calls are also used in 
TOPS-20 file processing and their calling sequences are fully 
described in the DECSYSTEM-20 Monitor Calls Reference Manual. TOPS-20 
usage information for these calls is found in the DECSYSTEM-20 Monitor 
Calls User's Guide. DECnet-20 usage information for all the 
network-related calls and the calling sequences for the network 
functions of MTOPR appear in the next three chapters. 



Table 2-1 
Monitor Calls Used in DECnet-20 



Monitor 
Call 


Network Function 


GTJFN 
OPENF 
BIN 
*BOOT 

SIN 

SINR 

BOUT 

SOUT 

SOUTR 

SIBE 

CLOSF 

MTOPR 

*NODE 


Get a network JFN 

Open a network connection 

Receive a data byte 

Provide maintenance and utility functions for 

communications software (see Table 2-2) 

Receive a data string 

Receive a data record (message) 

Transmit a data byte 

Transmit a data string 

Transmit a data record (message) 

Test for input buffer empty 

Close a network connection 

Perform device-dependent control functions 

(see Table 2-3) 

Set node and line characteristics 

(see Table 2-4) 



* BOOT and some functions of NODE are privileged monitor calls 

used in DECnet-20 system programs. Detailed descriptions of these 

monitor calls can be found in the DECSYSTEM-20 Monitor Calls 
Reference Manual. 
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Table 2-2 
BOOT Monitor Call Functions Used in DECnet-20 



Code 


Symbol 


Support* 


Purpose 





.BTROM 


a&b 


Puts line or DTE in MOP mode 
and activates the front-end ROM 
a: DN22 
b: DN20/21 or console front end 


1 


.BTLDS 


a&b 


Load secondary bootstrap 


2 


.BTLOD 


a&b 


Loads the front end 

a: DN22 

b: DN20/21 or console front end 


3 


.BTDMP 


b 


Dump the front end 


4 


.BTIPR 


a&b 


Initiate line protocol 


5 


.BTTPR 


a&b 


Terminate line protocol 


6 


.BTSTS 


a&b 


Determine line protocol 


7 


.BTBEL 


b 


Wait for front-end doorbell 


10 


.BTRMP 


a&b 


Read MOP message 


11 


.BTKML 


a 


Load KMC11 


12 


.BTKMD 


a 


Dump KMC11 


13 


.BTRLC 


a 


Return line counters 


14 


.BTCLI 


a&b 


Convert line-id to port number 


15 


.BTCPN 


a&b 


Convert port number to line-id 


16 


.BTSTA 


a 


Set station polling status 


17 


.BTSSP 


a 


Set line startup priority 


20 


.BTSTP 


a 


Set station polling priority 


21 


.BTSDD 


a 


Send DDCMP message 


22 


•BTRDD 


a 


Receive DDCMP message 


23 


.BTCHN 


a 


Assign a software interrupt 
channel 


24 


.BTSLS 


a 


Set line service type 



* Support indicates the hardware system on which these calls are 
valid: (a) for DECSYSTEM-2020 and (b) for DECSYSTEMs-2040/50/60 . 



Table 2-3 
MTOPR Monitor Call Functions Used in DECnet-20 



Code 


Symbol 


Purpose 


24 


. MOACN 


Set interrupt assignments 


25 


.MORLS 


Read link status 


26 


.MORHN 


Read host name 


27 


. MORTN 


Read task name 


30 


.MORUS 


Read user identification 


31 


.MORPW 


Read password 


32 


. MORAC 


Read account string 


33 


. MORDA 


Read optional data 


34 


.MORCN 


Read object type 


35 


.MORIM 


Read interrupt message 


36 


.MOSIM 


Send interrupt message 


37 


.MOROD 


Read object-descriptor 


40 


.MOCLZ 


Reject/Close a network 
connection 


41 


.MOCC 


Accept a network connection 


42 


.MORSS 


Read segment size 
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Table 2-4 
NODE Monitor Call Functions Used in DECnet-20 



Code 


Symbol 


Purpose 





.NDSLN 


Set local node name 


1 


.NDGLN 


Get local node name 


2 


.NDSNM 


Set local node number 


3 


.NDGNM 


Get local node number 


4 


.NDSLP 


Set loopback port 


5 


.NDCLP 


Clear loopback port 


6 


.NDFLP 


Find loopback port 


7 


.NDSNT 


Set network topology 
information 


10 


.NDGNT 


Get network topology 
information 


11 


.NDSIC 


Set topology change 
interrupt channel 


12 


.NDCIC 


Clear topology change 
interrupt channel 


13 


.NDGVR 


Get NSP version information 


14 


.NDGLI 


Get line information 


15 


.NDVFY 


Verify node name 
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CHAPTER 3 
ESTABLISHING A NETWORK CONNECTION 



In order to establish a network connection, you need one task that is 
willing to accept a connection (a target task) and another task to 
initiate the request for a connection (a source task) . In the 
following discussion, it is easier to imagine these two tasks as 
existing on different nodes; however, there is no restriction that 
prohibits tasks on the same node from engaging in a network dialogue 
with one another. 

A TOPS-20 task that wants to declare itself as a target task, 
available for network dialogue with other network tasks, must first 
obtain a Job File Number (JFN) identifying itself as a file on device 
SRV:. The target task must then open that SRV: file in order to have 
a logical link assigned to it by NSP. The task should also set up 
some form of software interrupt mechanism to be informed 
asynchronously of the arrival of a connect initiate message from a 
source task. Whenever a connect initiate message arrives, the target 
task can interrogate the connect attributes of the source task and 
decide whether to accept or reject the connection. 

A TOPS-20 task that wants to initiate a network dialogue with a 
declared target task must first obtain a JFN for a network connection 
identifying the target task as a file on device DCN:. It must then 
open that DCN: file to have a logical link assigned and to have a 
connect initiate message sent to the target task. 

A TOPS-20 task, if it so desires, can declare itself as a target task 
and also act as a source task by initiating a dialogue with some other 
task; the two actions are not mutually exclusive. 

Figure 3-1 is a general overview of the dialogue that takes place 
during the establishing of a network connection. 

A task at node DALLAS issues a GTJFN monitor call identifying itself 
as a target task named TEX. A subsequent OPENF monitor call informs 
the NSP task at node DALLAS that TEX is ready to receive connection 
requests from the network. 

A task at node BOSTON issues a GTJFN monitor call identifying itself 
as a task named TONY and specifying a network connection to task TEX 
at node DALLAS. A subsequent OPENF monitor call causes the NSP task 
at node BOSTON to send a connect initiate message to node DALLAS. 

The NSP task at node DALLAS knows that task TEX is accepting calls and 
forwards the connect initiate message. Task TEX decides whether to 
accept or reject the connection and returns a connect confirm or 
connect reject message to the source task TONY. 

The individual steps are explained in detail in the rest of this 
chapter . 
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Figure 3-1 Establishing a Network Connection 



3.1 OBTAINING A NETWORK JFN 

The first step in establishing a network logical link is to obtain a 

Job File Number (JFN) for a network file on either the SRV: or DCN: 

device. Use the GTJFN monitor call in either its short or long form 

as described in detail in the Monitor Calls Reference Manual . The 

network file specification can be submitted interactively via the 

terminal, accessed from memory, or (in the long form) developed by a 
combination of both methods. 
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The general format of a GTJFN file specification in TOPS-20 is: 

dev: <directory>f ilename. file type. genera t ion ;T;P;A 

When you use the GTJFN call to obtain a network JFN in DECnet-20, the 
network file specification takes the following form: 

dev: is replaced by one of the network pseudo-devices, 

SRV: or DCN:. 

<directory> is unused. 

filename is replaced by objectid-descr iptor for an SRV: 

file and by hostname-objectid-descr iptor for a 
DCN: file. 

file type is replaced by a task name uniquely identifying 

the task issuing the GTJFN. 

generation is unused. 

;T;P;A are replaced by network attributes. 

The individual fields in the network file specification are described 
in detail in the following subsections. 



3.1.1 Specifying a Target Task 

Use the following format of the network file specification to obtain a 
JFN identifying yourself as a target task: 

SRV:objectid-descr iptor . taskname 

where : 

SRV: is the logical device name for a target task. 

objectid is part of an optional generic identification for a 
target task. If included, it must be a nonzero object 
type expressed as a decimal number or an object name 
(see Appendix B) . The numbers 1 through 127 are 
reserved for DECnet system tasks and require enabled 
WHEEL or OPERATOR privileges. Numbers 1 through 127 
should not be assigned to user tasks unless the task 
provides the service and uses the protocol implied by 
the object type (see Appendix B) . Numbers 128 through 
255 are available to all tasks. If objectid is not 
specified, the target task must be addressed by its 
unique task name. 

- (hyphen) is a subfield separator that is required only if the 
descriptor is specified. 
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descriptor is an optional modifier to be associated with the 
objectid. If specified, it must be 1 to 16 characters 
in length and contain only alphanumerics, hyphens, 
dollar signs, or underscores. If objectid is not 
specified, the descriptor must also be omitted. If 
descriptor is specified, it must also appear in the 
specification used by the source task to address this 
task (see Section 3.1.2). 

NOTE 

Some DECnet implementations do not allow a 
descriptor to be associated with a nonzero 
object type. When communicating with a 
non-DECnet-20 node, read the applicable 
documentation to determine any restrictions 
on the generic task identification. 

. (period) is a separator character and is required only if task 
name is specified. 

taskname is the unique task name by which a task is to be 
addressed independent of its generic identification. 
If taskname is specified, it must be 1 to 16 characters 
in length and contain only alphanumerics, hyphens, 
dollar signs, or underscores. If taskname is not 
specified, the monitor will assign one. (To 
subsequently determine the monitor-assigned task name, 
use the read task name function described in Section 
3.4.3.) 

The maximum lengths of the variable fields in the SRV: file 
specification as imposed by TOPS-20 are: 

objectid see object type and name in Appendix B 

descriptor 16 characters 

taskname 16 characters 

The above maximums may be reduced by any size limitations imposed by 
the DECnet product running on the remote system. 
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3.1.2 Specifying a Network Connection 

Use the following format of the network file specification to obtain a 
JFN identifying a target task that you wish to connect to: 

DCN: hostname -object id -descriptor . taskname ;A1;A2. . . 

where: 



DCN: 
hostname 

- (hyphen) 
objectid 



- (hyphen) 
descriptor 



is the logical device name for a network connection. 

is the node name of the node on which the target task 
is running. If this field is omitted, the target task 
is assumed to be running on the local node. 

is a subfield separator and is required. 

is the identification of the target task. It is an 
object name or a numeric object type when addressing a 
target task by its generic identification (see Appendix 
B) . The special object type (or corresponding object 
name TASK) is used to address a target task by its 
unique task name. The objectid, when specified as a 
numeric object type, must be entered in decimal. This 
subfield is required. 



is a subfield separator that is required only 
descriptor is specified. 



if the 



is an optional modifier to be associated with the 
objectid. If objectid is TASK or 0, this field must be 
the unique task name of the target task. If objectid 
identifies some other object type, this field must be 
the descriptor specified by the target task. 



NOTE 

Some DECnet implementations do not allow a 
descriptor to be associated with a nonzero 
object type. When you wish to communicate 
with a non-DECnet-20 node, read the 
applicable documentation to determine any 
restrictions on the generic task 
identification. 



. (period) 
taskname 



is a separator character 
taskname is specified. 



and is required only if 



is the unique taskname of the source task initiating 
the network connection. If taskname is specified, it 
must be 1 to 16 characters in length and contain only 
alphanumerics, hyphens, dollar signs, or underscores. 
If taskname is not specified, the monitor will assign 
one. (To subsequently determine the monitor-assigned 
task name, use the read task name function described in 
Section 3.4.3.) 
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;A1;A2... are a collection of attributes of the source task that 
are included in the connect initiate message sent to 
the target task. These attributes can be used by the 
target task to validate a network connection or to 
perform any other handshaking functions agreed to by 
both tasks. The allowable attributes are: 



;USERID:userid 



; PASSWORD : password 



where userid consists of 1 to 16 
contiguous alphanumeric ASCII 
characters (including the hyphen, 
dollar sign, and underscore) 
identifying the source task. 

Example: 

; USERID: ALIBABA 

where password consists of 1 to 8 
contiguous alphanumeric ASCII 
characters (including the hyphen, 
dollar sign, and underscore) 
required by the target task to 
validate the connection. 



; BPASSWORD : password 



Example : 

; PASSWORD: SESAME 

The password can also be specified 
in binary to allow non-ASCII 
characters. The keyword for this 
type of entry is BPASSWORD. 

where password, in this context, 
consists of 1 to 8 octal triplets 
representing the required 
password. Each triplet represents 
an 8-bit byte. 

Example : 



BPASSWORD: 123056 002 



;CHARGE:acctno 



where acctno consists of 1 to 16 
contiguous alphanumeric ASCII 
characters (including the hyphen, 
dollar sign, and underscore) 
representing the source task's 
account identification. 



Example : 

; CHARGE :ACCT-13C 
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;DATA:userdata 



where userdata consists of 1 to 16 
contiguous alphanumeric ASCII 
characters (including the hyphen, 
dollar sign, and underscore) 
representing user data. 

Example : 

;DATA:THIS-IS-A-TEST 

The user data can also be 
specified in binary to allow 
non-ASCII characters. The keyword 
for this type of entry is BDATA. 

where userdata, in this context, 
consists of 1 to 13 octal triplets 
representing user data. Each 
triplet represents an 8-bit byte. 

Example : 

;BDATA:231337001 



The attributes of a source task can be retrieved by a 
target task via functions of the MTOPR monitor call 
(see Section 3.4). 



;BDATA:userdata 



The maximum lengths of the variable fields in the DCN: 
specification as imposed by TOPS-20 are: 



file 



hostname 

objectid 

descriptor 

hostname -object id -de scrip tor 

taskname 

f n _L i c\ £ • • • 



6 characters 

see object type and name in Appendix B 

16 characters 

39 characters including the hyphens 

16 characters 

see the description of the individual 
attribute 



The above maximums may be reduced by any size limitations imposed by 
the DECnet product running on the remote host system. 



3.1.3 Examples of Network File Specifications 

The following examples show various ways that a target task can 
declare itself and the corresponding ways that a source task must use 
to address the target task. These examples assume two DECnet-20 nodes 
with host node names of BOSTON and DALLAS. 
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Example 1 

A task at node BOSTON wants to declare itself as the unique target 
task SAM. It does so with the specification: 

SRV: .SAM 

In order to request a connection to SAM at node BOSTON, a task TEX at 
node DALLAS would specify: 

DCN : BOSTON-TASK-SAM . TEX 

A task COD at node BOSTON requesting a connection to SAM at node 
BOSTON can omit the node name in the specification because the target 
node is the local node. It need only specify: 

DCN: -TASK-SAM. COD 

Example 2 

A task at node BOSTON wants to declare itself as a generic service 
task, object type 128. It does so with the specification: 

SRV:128 

Task TEX at node DALLAS can connect to the above task with the 
specification: 

DCN: BOSTON-128.TEX 

Assume that the BOSTON task had included a descriptor in its 
specification such as: 

SRV:128-PART1 

The DALLAS task would then have to modify its specification to: 

DCN : BOSTON-128-PART1 . TEX 

Example 3 

Several tasks at node BOSTON, running the same utility program, want 
to declare themselves both generically as object type 129 and uniquely 
by task name. The respective specifications used to declare three 
such tasks are: 

SRV:129.TOM 
SRV: 129. DON 
SRV: 129. TONY 

A task TEX at node DALLAS, wanting to avail itself of the utility but 
not caring which copy of the program completes the connection, can use 
the specification: 

DCN:BOSTON-129.TEX 

If, for some reason, TEX had to connect to the particular task TONY, 
the specification must be submitted as: 

DCN : BOSTON-TASK-TONY . TEX 
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Example 4 

A task at node BOSTON declares itself as the target task XDATA with 
the specification: 

SRV: .XDATA 

Assume that the task XDATA restricts connections to those remote tasks 

that have a valid userid, password, and charge account. A 

specification from task TEX at node DALLAS to connect to XDATA would 
then have to include the above attributes, for example: 

DCN : BOSTON-TASK-XDATA . TEX ; USERID : RITTER; PASSWORD : SESAME 
; CHARGE :ACCT-XYZ 

The target task can then confirm the connect requirements by 
retrieving the network attributes using the read logical link data 
functions of the MTOPR monitor call. These functions are described in 
Section 3.4. 



3.2 OPENING A NETWORK JFN 

Having obtained a JFN for a network file specification, the network 
task must then open the file with the OPENF monitor call* The monitor 
passes control to the appropriate device handler, which for the SRV: 
and DCN: devices is the local NSP task. The events that occur when a 
network file is opened depend on whether the file represents a target 
task or a source task. 



3.2.1 Opening a Target Task JFN 

An OPENF monitor call for a JFN that represents a target task implies 
that the task is ready to accept connect initiate messages from other 
tasks in the network. The local NSP performs the following: 

• Constructs a link data base for this connection. 

• Places the target task on a list of available connections. 

Subsequently, when a connect initiate message is received from a 
source task, the local NSP performs the following: 

• Searches the list of available connections for a matching 
generic or unique task identification. 

• Notifies the appropriate target task via a connect interrupt 
that it has a connect request pending and modifies the link 
status appropriately. 

The target task can then access the logical link data (see Section 
3.4) to determine whether to accept or reject the connection. 
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3.2.2 Opening a Network Connection 

An OPENF monitor call for a JFN that represents a network connection 
implies a request for a connection to a target task. The local NSP 
task performs the following: 

• Constructs a link data base for this connection. 

• Generates a connect initiate message and forwards it to the 
host node specified by the host name in the DCN: file 
specification. 

• Processes the resulting connect confirm or connect reject 
message, and notifies the source task of the acceptance or 
rejection via a connect interrupt. 

NOTE 

The successful completion of the OPENF 
monitor call for a network connection 
does not necessarily mean that a connect 
confirm message has been received by the 
local NSP. The source task should read 
the link status (Section 3.4.1) to 
ensure that a connection has been 
completed. 



3.2.3 Limit on Open Links 

DECnet-20 software sets a user quota of four open links per job. 
These can be any combination of SRV: and DCN: types. However, a 
task running with enabled WHEEL or OPERATOR privileges is not bound by 
this quota and may open as many links as the system will allow. 

The system quota of open links varies according to the amount of free 
space available at the time. Free space, in turn, is dependent upon 
the current demands of other processes. Whenever a request to open a 
link cannot be completed because of insufficient free space, an 
appropriate error code is returned. 

When DECnet-20 is generated on a DECSYSTEM-2040 , 2050, 2060, the 
maximum number of logical links is set for the individual site 
according to the site's configuration. See Chapter 9 in this manual. 



3.3 ENABLING FOR NETWORK INTERRUPTS 

Whenever a MACRO task uses a SIN or SINR monitor call to input a data 
string from the network, the task will stop running (block) if no data 
is available. In situations where a network task is supporting 
multiple links, blocking after each SIN or SINR call severely impacts 
the speed of data transmission. Asynchronously notifying the task of 
the arrival of network data reduces idle time and increases the 
overall throughput. 
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DECnet-20 software provides a function of the MTOPR monitor call that 
allows a network task to enable software interrupt channels for any 
combination of the following types of network events: 

• connect event pending (connect initiate, connect confirm) 

• interrupt message available 

• data message or disconnect received 

The MTOPR calling sequence to enable for network interrupts expects 
the following monitor call arguments to be placed in the specified 
accumulators: 

AC1: The JFN of the logical link 

AC2: .MOACN (function code) 

AC3: Control information specifying the changes in the 
interrupt assignments for this link. This control 
information is placed in three 9-bit fields that are 
defined as follows: 

Field Symbol Used to signal 

B0-B8 MOfcCDN Connect event pending 
B9-B17 MO%INA Interrupt message available 
B18-B26 MO%DAV Data available 

The content of each of these fields must be one of the 
following: 

Value Meaning 

nnn Enable the channel specified by nnn 

.MOCIA Clear the interrupt 

.MONCI Do not change the previous setting 

Valid channel numbers are 0-5 and 23-35, decimal. 
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3.3.1 Example 

The following program segment illustrates one method of enabling 
interrupt channels for the three types of network events: 

; SET UP THE INTERRUPT CHANNELS AND GO INTO WAIT STATE 



ENACHN: 



PAUSE: 



MOVE I 

MOVE 

SIR 

MOVX 

AIC 

EIR 

MOVE 

MOVE I 

MOVX 

MTOPR 

WAIT 



Tl, .FHSLF 

T 2 , [ LE VTAB , , C HNTAB ] 

T2,7B2 



T1,NETJFN 
T2, .MOACN 



IDENTIFY CURRENT PROCESS 
SPECIFY TABLE ADDRESSES 
DEFINE PSI SYSTEM TABLES 
SET BITS FOR CHAN 0,1,2 
ACTIVATE CHANNELS 0,1,2 
ENABLE THE SYSTEM 
GET NETWORK JFN 
SET UP FUNCTION 



T3 , <FLD ( ,MO%CDN) +FLD ( 1 ,MO%DAV) +FLD ( 2 ,MO%INA) > 

; ISSUE THE CALL 
;WAIT FOR INTERRUPT 



LEVTAB: PC 




CHNTAB: 1,, HELLO 

1 , , HAVDAT 

1, ,INTRPT 

REPEAT ~D33,<EXP 0> 
PC: BLOCK 1 



; LEVEL 1 PC ADDRESS 



; CONNECT INTERRUPT 

;DATA AVAILABLE INTERRUPT 

; INTERRUPT MESSAGE INTERRUPT 

; UNUSED INTERRUPT CHANNELS 

; LEVEL 1 PC 



3.4 READING LOGICAL LINK DATA 

Associated with each open logical link is a link data base, created 
and maintained by the local NSP. This data base contains information 
such as link status, link control data, allowable segment sizes, and 
data governing the transmission and receipt of data and interrupt 
messages. 

Whenever a target task is notified of a pending connect request from a 
source task, the target task's data base will contain the connect 
attributes submitted by the source task. These attributes, as well as 
other link data, can be retrieved by a target task via network 
functions of the MTOPR monitor call. These functions retrieve the 
source's host name, task name, user identification, password, user 
account number, and optional user data. Using this data, the target 
task can decide whether to accept or reject the connection. 
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3.4.1 Reading the Link Status 

The read link status function of MTOPR returns a 36-bit word of 
information regarding the status of the logical link. 

The calling sequence expects the following monitor call arguments to 
be placed in the specified accumulators: 

AC1: The JFN of the logical link 

AC2: .MORLS (function code) 

The monitor call returns the following information in AC3: 

AC3: Flag bits in the left half and a disconnect code in the 
right half 

The flag bits are: 

Symbol Bit Meaning 

Link is connected 

Link is a server 

Link is waiting for a connect 

Link is waiting for a connect confirm 

Link has the end of, or entire, message to be read 

Link has been aborted 

Link has been disconnected normally 

Link has an interrupt message available 

Link has been previously connected 

The various disconnect codes are listed in Appendix A. If a 
disconnect code does not apply to the current status of the link, the 
value of the right half of AC3 will be zero. 



MO%CON 


BO 


MO%SRV 


Bl 


MO%WFC 


B2 


MO%WCC 


B3 


MO%EOM 


B4 


MO%ABT 


B5 


MO%SYN 


B6 


MO%INT 


B7 


MO%LWC 


B8 



Example 

Assume that a source task obtains a JFN for a connection to a target 
task and opens the JFN. A successful return from the OPENF call does 
not necessarily mean that the local NSP has received a connect confirm 
message from the target node or task. To ensure that a connection 
really exists, you can use a coding sequence such as: 



CHKCON: 


MOVE 


T1,NETJFN 


GET NETWORK JFN 




MOVE I 


T2,. MORLS 


SET UP FUNCTION 




MTOPR 




ISSUE THE CALL 




ERJMP 


JSYSXX 


•JSYS ERROR 




TXNE 


T3,MO%CON 


NOW CONNECTED? 




JRST 


CNCTED 


YES 




TXNE 


T3,MO%WCC 


NO, WAITING FOR CC? 




JRST 


[MOVEI T1,~D1000 


■YES, WAIT A 






DISMS 


SECOND AND 






JRST CHKCON] 


TRY AGAIN 




TXNN 


T3,M0%LWC 


NO, EVER CONNECTED? 




JRST 


REJECT 


•NO, CI REJECTED 




JRST 


ABORT 


■YES, LINK WAS ABORTED 


CNCTED: 






■OK, CONTINUE 
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3.4.2 Reading the Host Name 

The read host name function of MTOPR returns the ASCII name of the 
node at the other end of the logical link. 

The calling sequence expects the following monitor call arguments to 
be placed in the specified accumulators: 

AC1: The JFN of the logical link 

AC2: .MORHN (function code) 

AC3: A byte pointer to the location where the node name is to 
be stored 

The monitor call returns with an updated pointer in AC3 and the node 
name stored as specified. 

Example 

A target task may wish to give special connection privileges to tasks 
running on a particular remote node. The following program segment 
will retrieve the name of the node submitting the current connect 
request and store it at location NODNAM: 



GTHNAM: MOVE 
MOVE I 
HRROI 
MTOPR 
ERJMP 



T1,NETJFN 
T2, .MORHN 
T 3, NODNAM 

JSYSXX 



GET NETWORK JFN 
SET UP FUNCTION 
POINTER TO NODE NAME 
ISSUE THE CALL 
JSYS ERROR 



NODNAM: BLOCK 



; REMOTE NODE NAME 
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3.4.3 Reading the Task Name 

The read task name function of MTOPR returns the unique task name that 
is associated with your end of the logical link. If you had defaulted 
the task name in the network file specification, the call returns the 
monitor-supplied task name. In DECnet-20, the default or 
monitor-supplied task name is actually a unique number. 

The calling sequence expects the following monitor call arguments to 
be placed in the specified accumulators: 

AC1: The JFN of the logical link 

AC2: .MORTN (function code) 

AC3: A byte pointer to the location where the task name is to 
be stored 

The monitor call returns with an updated pointer in AC3 and the task 
name stored as specified. 

Example 

Target tasks, especially those that perform utility functions, often 
default their task names because they do not expect to be addressed 
other than genericaiiy. If a connected source task wishes to initiate 
a second connection to your particular target task, the connected task 
requires your unique task name. You can first retrieve the monitor 
assigned name using a program segment as follows: 



GTDTNM: 


MOVE 


T1,NETJFN 




MOVE I 


T 2,. MORTN 




HRROI 


T3,TSKNAM 




MTOPR 






ERJMP 


JSYSXX 



GET NETWORK JFN 
SET UP FUNCTION 
POINTER TO TASK NAME 
ISSUE THE CALL 
JSYS ERROR 



TSKNAM: BLOCK 



; LOCAL TASK NAME 



Once retrieved, the task name can be sent to the connected source task 
via a data transfer or interrupt message (see Sections 4.1.1 and 
4.2.1) . 
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3.4.4 Reading the User Name 

The read user name function of MTOPR is valid only for target tasks. 
It returns the source task's ASCII user identification supplied in the 
connect initiate message. 

The calling sequence expects the following monitor call arguments to 
be placed in the specified accumulators: 



AC1 
AC 2 
AC 3 



The JFN of the logical link 

.MORUS (function code) 

A byte pointer to the location where 
identification is to be stored 



the 



user 



The monitor call returns with an updated pointer in AC3 and the user 
identification stored as specified. If no user identification was 
supplied by the source task, AC3 continues to point to the beginning 
of the string and a null is returned as the only character. 



Example 

A target task may include code to reject connect initiate requests 
from all but a select group of userids. The following program segment 
retrieves the userid of the current connect request: 



GTUSID: MOVE 
MOVE I 
MOVE 
MTOPR 

ERJMP 
CAMN 
JRST 



T1,NETJFN 
T2, .MORUS 
T3,UIDPTR 

JSYSXX 

T3,UIDPTR 

REJECT 



GET NETWORK JFN 
SET UP FUNCTION 
POINTER TO USERID 
ISSUE THE CALL 
JSYS ERROR 
CHECK IF ANY USERID 
NO - REJECT 



check if userid is valid 



USERID: BLOCK 
UIDPTR: POINT 



7, USERID 



; SOURCE USERID 
; USERID POINTER 
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3.4.5 Reading the Password 

The read password function of MTOPR is valid only for target tasks. 
It returns the source task's password supplied in the connect initiate 
message. 

The calling sequence expects the following monitor call arguments to 
be placed in the specified accumulators: 

AC1: The JFN of the logical link 

AC2: .MORPW (function code) 

AC3: A byte pointer to the location where the password is to 
be stored. Passwords may be binary; therefore, the byte 
pointer should accommodate 8-bit bytes unless you know 
that the password is ASCII. 

The monitor call returns with an updated pointer in AC3 and the source 
task's password stored as specified. AC4 contains the number of bytes 
in the string; a zero value indicates that no password was supplied 
by the source task. 

Example 

In addition to screening a source task's user id, a target tasK may 
require the submission of a password before confirming a connect 
request. Whereas a userid is usually permanent, a password can be 
changed periodically to ensure security. The following program 
segment retrieves the password submitted by a source task in its 
connect request. The two tasks have agreed to use ASCII passwords: 



GTPSWD: MOVE 


T1,NETJFN 


MOVE I 


T 2,. MORPW 


MOVE 


T3,PWDPTR 


MTOPR 




ERJMP 


JSYSXX 


JUMPE 


T4, REJECT 



GET NETWORK JFN 

SET UP FUNCTION 

POINTER TO PASSWORD 

ISSUE THE CALL 

JSYS ERROR 

REJECT IF NO PASSWORD 



check for valid password 



PWDPTR: POINT 
PASSWD: BLOCK 



7,PASSWD 
2 



; PASSWORD POINTER 
; SOURCE PASSWORD 
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3.4.6 Reading the Account String 

The read account string function of MTOPR is valid only for target 
tasks. It returns the ASCII account string supplied by the source 
task in the connect initiate message. 

The calling sequence expects the following monitor call arguments to 
be placed in the specified accumulators: 

AC1: The JFN of the logical link 

AC2: .MORAC (function code) 

AC3: A byte pointer to the location where the account string 
is to be stored 

The monitor call returns with an updated pointer in AC3 and the source 

task's account string stored as specified. If no account string was 

supplied by the source task, AC3 continues to point to the beginning 
of the string and a null is returned as the only character. 

Example 

A target task that includes a cost distribution of its services may 
set up a chart of accounts and require each connecting task to supply 
an account identification. With this information the target task can 
control access, set budgets, check overruns, and provide billing data. 
The following program segment retrieves the account string supplied in 
a connect initiate message: 



GTACCT: MOVE 
MOVE I 
MOVE 
MTOPR 

ERJMP 
CAMN 

JRST 



T1,NETJFN 
T 2,. MORAC 
T3,ACCPTR 

JSYSXX 

T3,ACCPTR 

REJECT 



GET NETWORK JFN 
SET UP FUNCTION 
POINTER TO ACCT NO. 
ISSUE THE CALL 
JSYS ERROR 

CHECK IF ANY ACCT NO, 
NO - REJECT 



process the account number 



ACCTNO: BLOCK 
ACCPTR: POINT 



7, ACCTNO 



; ACCOUNT STRING 
;ACCT NO. POINTER 
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3.4.7 Reading the Optional Data 

The read optional data function of MTOPR returns the optional data 
supplied in any of the connect or disconnect messages. 

The calling sequence expects the following monitor call arguments to 
be placed in the specified accumulators: 

AC1: The JFN of the logical link 

AC2: .MORDA (function code) 

AC3: A byte pointer to the location where the optional user 
data is to be stored. This field may be binary; 
therefore, the byte pointer should accommodate 8-bit 
bytes unless you know that the data is ASCII. 

The monitor call returns with an updated pointer in AC3 and the 
optional data stored as specified. AC4 contains the number of bytes 
in the data string; a zero value indicates that no optional data was 
supplied. 

Example 

The user level protocol, agreed to by two corresponding tasks, may 
state that optional user data will always accompany a connect reject 
message. The following program segment will retrieve optional user 
data in binary: 



GTDATA : MOVE 
MOVE I 
MOVE 
MTOPR 

ERJMP 
JUMPE 



T1,NETJFN 
T2, .MORDA 
T3,DATPTR 

JSYSXX 
T4,NODATA 



GET NETWORK JFN 
SET UP FUNCTION 
POINTER TO USER DATA 
ISSUE THE CALL 
JSYS ERROR 
BRANCH IF NO DATA 



DATPTR: POINT 
USRDAT: BLOCK 



8,USRDAT 
4 



;USER DATA POINTER 
;USER DATA 
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3.4.8 Reading the Object Type 

The read object type function of MTOPR is valid only for target tasks. 
It returns the object type that was used by the source task to address 
this connection. The result indicates whether the local task was 
addressed by its generic object type or its unique network task name. 



The calling sequence expects the following monitor call arguments to 
be placed in the specified accumulators: 

AC1: The JFN of the logical link 

AC2: .MORCN (function code) 

The monitor call returns with the object type in AC3. A zero object 

type indicates that the target task was addressed by its unique 

network task name; a nonzero value indicates that it was addressed by 
its generic object type. 



Example 

Assume for example that the services of a target task depend on 
whether a source task connects to it by generic object type or by 
unique task name. The following program segment retrieves the object 
type used in the connect initiate message: 

GET NETWORK JFN 

SET UP FUNCTION 

ISSUE THE CALL 

JSYS ERROR 

TEST TYPE OF CONNECT 

CONNECTED BY OBJECT TYPE 



; CONNECTED BY TASK NAME 



GTOBJT: 


MOVE 


T1,NETJFN 




MOVE I 


T2, .MORCN 




MTOPR 






ERJMP 


JSYSXX 




JUMPE 


T3, TSKCON 


OBJCON: 






TSKCON: 
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3.4.9 Reading the Object-Descriptor 

The read object-descriptor function of MTOPR is valid only for target 
tasks. It returns the unique identification of the source task. This 
identification is in the format of object-descriptor and the contents 
depend on the DECnet implementation on the remote host. In addition, 
if the source task is running on a system that provides for group and 
user codes, this information is also returned. If the source task is 
on a DECnet-20 host, the data returned to the target task is 
TASK-taskname. 

The calling sequence expects the following monitor call arguments to 
be placed in the specified accumulators: 



AC1 
AC 2 
AC 3 



The JFN of the logical link 

.MOROD (function code) 

A byte pointer to the location where the 
object-descriptor of the source task is to be stored 



The monitor call returns with an updated pointer in AC3 and the 
object-descriptor stored as specified. In addition, if the source 
host system uses group and user codes, AC4 contains the following: 

AC4: The group code in the left half and the user code in the 

right half 

If the source host system does not provide for group or user codes, or 
if none were provided in the connect initiate message, AC4 contains 
zeros. 



Example 



A target task can retrieve the unique identification 
task with the following program segment: 



of the source 



GTOBJD: MOVE 


T1,NETJFN 


MOVE I 


T 2,. MO ROD 


HRROI 


T3,OBJDES 


MTOPR 




ERJMP 


JSYSXX 


JUMPN 


T4,[HRRZM T4,USRCOD 




HLRZM T4,GRPC0D 




JRST .+1] 



GET NETWORK JFN 
SET UP FUNCTION 
POINTER TO OBJ. DESC 
ISSUE THE CALL 
JSYS ERROR 
SAVE USER CODE 
SAVE GROUP CODE 
RETURN 



OBJDES: BLOCK 5 
GRPCOD: BLOCK 1 
USRCOD: BLOCK 1 



OBJECT-DESCRIPTOR 
GROUP CODE 
USER CODE 
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3.4.10 Reading the Segment Size 

The read segment size function of MTOPR returns the maximum segment 
size that can be sent over this link. The maximum segment size that 
can be sent over a logical link is a function of the buffering 
capabilities of the remote node and the particular implementation of 
DECnet that is running on the remote node. The local task can use 
this value to determine the optimum size of data records being 
transmitted over the link. 

The calling sequence expects the following monitor call arguments to 
be placed in the specified accumulators: 

AC1: The JFN of the logical link 

AC2: .MORSS (function code) 

The monitor call returns with the maximum segment size, in bytes, in 
AC3. If the link has not been established, the monitor call takes the 
error return. 

Example 

The maximum segment size for a source task is transmitted to the 
target NSP in the connect initiate message. The target NSP, in turn, 
returns the target task's maximum segment size in the connect confirm 
message that is sent back to the source NSP. Each task can then 
retrieve this value with a program segment such as the following: 



GTSGSZ 



MOVE 
MOVE I 
MTOPR 

ERJMP 
MOVEM 



T1,NETJFN 
T2,. MORSS 

JYSXX 
T3,SEGSIZ 



GET NETWORK JFN 
SET UP FUNCTION 
ISSUE THE CALL 
JSYS ERROR 
STORE SEGMENT SIZE 



SEGSIZ: BLOCK 



;MAX SEGMENT SIZE 



3-22 



ESTABLISHING A NETWORK CONNECTION 



3.5 ACCEPTING OR REJECTING A CONNECTION 

When the target task has decided to accept or reject the connection, 
it must inform the local NSP, via the monitor, of its intention. Two 
MTOPR monitor call functions are provided: .MOCC to accept a 
connection and return some data, and .MOCLZ to reject the connection 
and return some data along with a specific reject reason. If no data 
or specific reject reason is to be returned, the target task can 
accept or reject the connection implicitly, without using either of 
the two MTOPR functions. This is explained in the following 
subsections. 



3.5.1 Accepting the Connection 

Connections can be accepted either explicitly or implicitly. 

You can accept a connection explicitly by sending a connect confirm 
message to the source task via the .MOCC function of the MTOPR monitor 
call. This method allows you to include up to 16 bytes of optional 
data in the connect confirm message. 

The calling sequence expects the following monitor call arguments to 
be placed in the specified accumulators: 



AC1 
AC 2 
AC 3 
AC 4 



The JFN of the logical link 

.MOCC (function code) 

A byte pointer to any data to be returned 

The count of bytes in the data string. A zero indicates 
no data. The maximum amount of data is 16 bytes. 



You can accept a connection implicitly by performing one of the 
operations that NSP recognizes as indicating acceptance. These 
operations are: 

• Issuing an output monitor call such as BOUT, SOUT, or SOUTR to 
the network JFN 

• Issuing an input monitor call such as BIN, SIN, or SINR to the 
network JFN 

• Placing yourself in an input or output wait state 

When NSP senses one of the above conditions, it assumes that you are 
accepting the connection and sends a connect confirm message to the 
source task. The connect confirm message sent by NSP does not allow 
for optional data; if you must return optional data, use the explicit 
acceptance. 



3.5.2 Rejecting the Connection 

Connections can be rejected either explicitly or implicitly. 

You can reject a connection explicitly by sending a connect reject 
message to the source task via the .MOCLZ function of the MTOPR 
monitor call. This method allows you to include a reject code as well 
as up to 16 bytes of optional data in the connect reject message. 
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The calling sequence expects the following monitor call arguments to 
be placed in the specified accumulators: 

AC1: The JFN of the logical link 

AC2: A reject code in the left half and .MOCLZ in the right 
half 

AC3: A byte pointer to any data to be returned 

AC4: The count of bytes in the data string. A zero indicates 
no data. The maximum amount of data is 16 bytes. 

The reject code in AC2 is a 2-byte, NSP-defined decimal number 
indicating the reason that a target task is rejecting a connection. A 
list of these codes, applicable to both user and system tasks, appears 
in Appendix A. 

You can reject a connection implicitly by closing the JFN of the 
logical link before accepting the connection either explicitly or 
implicitly. To close the JFN, use the CLOSF monitor call. When NSP 
senses that the logical link's JFN has been closed in response to a 
connect initiate message, NSP sends a connect reject message to the 
source task with a reject code of 38 (user aborted) . In this 
situation, you must reopen the JFN in order to receive subsequent 
connect initiate messages. 



3.5.3 Examples 

The following program segment will send a connect confirm message to 
the source task that requested the connection: 



ACCEPT: MOVE Tl,NETJFN 

MOVE I T2,.M0CC 

SETZ T4, 
MTOPR 

ERJMP JSYSXX 



GET THE NETWORK JFN 
CODE TO ACCEPT 
FLAG NO OPT. DATA 
ISSUE THE CALL 
JSYS ERROR 



To include up to 16 bytes of ASCII user data with the connect confirm 
message, modify the above segment as follows: 



ACCEPT: MOVE 
MOVE I 
MOVE 
MOVE I 
MTOPR 



T1,NETJFN 

T2,.MOCC 

T3, [POINT 7,MSGC; 

T4,~D16 



ERJMP JSYSXX 



GET THE NETWORK JFN 
CODE TO ACCEPT 
POINTER TO USER DATA 
USER DATA BYTE COUNT 
ISSUE THE CALL 
JSYS ERROR 



MSGC: ASCIZ /OPEN UNTIL 10 PM/ 
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The following program segments will send a connect reject message to 
the source task that requested the connection. The reason for the 
rejection is coded as 34 - access not permitted. With no user data, 
the instruction sequence is: 



REJECT: MOVE 
MOVE I 
HRLI 
SETZ 
MTOPR 



T1,NETJFN 
T2,.MOCLZ 
T2, .DCX34 
T4, 



ERJMP JSYSXX 



GET THE NETWORK JFN 
CODE TO REJECT 
ADD REJECT CODE 34 
FLAG NO USER DATA 
ISSUE THE CALL 
JSYS ERROR 



Because reject code 34 is somewhat general, you may want to include 
ASCII user data to clarify the rejection. You can modify the above 
sequence as follows: 



REJECT: MOVE 
MOVE I 
HRLI 
MOVE 
MOVE 
MTOPR 



T1,NETJFN 

T2, .MOCLZ 

T2, .DCX34 

T3, [POINT 7,XPWD] 

T4,~D14 



ERJMP JSYSXX 



GET THE NETWORK JFN 
CODE TO REJECT 
ADD REJECT CODE 34 
POINTER TO REJECT MSG 
REJECT MSG BYTE COUNT 
ISSUE THE CALL 
JSYS ERROR 



XPWD: ASCIZ /WRONG PASSWORD/ 

Figures 5-1 and 5-2 are examples, in program context, of some 
programming sequences described in this chapter. 



of the 
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Once a network connection has been established, the task at either end 
of the logical link can send information to the task at the other end. 
DECnet-20 provides for three general types of information exchange: 

• Data transfers 

• Interrupt messages 

• Network utility messages 

Data transfers are primarily used by network tasks to move large 
blocks of data. Interrupt messages are used by network tasks to 
exchange small amounts (16 bytes or less) of high priority data that 
are not sequentially related to the main data flow. Network utility 
messages include link control messages, link service messages, and 
ACK/NAK messages. 

Data transfers and interrupt messages are discussed in the remainder 
of this chapter. Network utility messages are internal to the 
DECnet-20 software and transparent to the user network tasks; they 
are described in the Network Services Protocol (NSP) functional 
specification listed in the bibliography of Appendix D. 



4.1 TRANSFERRING DATA 

Data transfers over a logical link involve the segmentation and 
restructuring of data at both the logical and physical link levels. 
The local NSP accepts data from the user program, segments it to 
conform to the maximum segment size allowable on that logical link, 
precedes each segment with an NSP header, and passes these NSP 
segments to the physical link management, DDCMP. DDCMP, in turn, 
segments the input from NSP to conform to the maximum segment size 
allowable on the physical link, precedes each segment with a DDCMP 
header to form a packet, and sends these packets over the physical 
media to the destination node. 

At the destination node the reverse procedure takes place. DDCMP 
strips each packet of its DDCMP header and passes the packet data to 
the local NSP. The local NSP reassembles the NSP segments, strips off 
the NSP headers, and passes the data to the receiving task. 

Data transfers on a logical link can take one of two forms: logical 
messages or continuous byte streams. 
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The logical message format provides for the transmission of 
information in discrete logical units called records, or messages. 
Data transmitted in this format can be retrieved by the receiving task 
on a message-by-message basis with NSP taking care of delimiting each 
logical unit. 

The continuous byte stream format, on the other hand, does not 
implement any end-of-message indicators. Data transmitted in this 
format is presented to the receiving task as a continuous stream of 
data with no indication by NSP of the end of one message and the 
beginning of another. The receiving task must reconstruct the 
original messages via some prearranged protocol agreed to by both user 
tasks. 

The logical message format allows for simpler user retrieval routines 
at the expense of not taking full advantage of the monitor's buffering 
capabilities. The continuous byte stream format allows NSP and DDCMP 
to pack data buffers without regard for the ends of messages; 
however, the user retrieval routines must then analyze the input 
stream and reconstruct the original logical messages. 



4.1.1 Sending Data 

You can send data to another task with either the SOUT or the SOUTR 
monitor call. In general, use SOUTR to send data in the logical 
message format and SOUT to send data as a continuous byte stream. 

The exclusive use of SOUTR usually implies that both you and the other 
task have agreed to exchange information in the form of messages with 
some stated maximum length. Each use of the SOUTR monitor call 
results in the transmission of a logical message terminated with an 
end-of-message indicator. A DECnet-20 receiving task can then 
retrieve the message with the SINR (read record) monitor call (see 
Section 4.1.2) . 

The exclusive use of SOUT or BOUT usually implies that both you and 
the other task have agreed to exchange information in the form of a 
continuous byte stream. You can repeatedly fill your data buffer and 
execute the SOUT monitor call. Each SOUT transmits a buffer's worth 
of data to the destination node where it is presented to the receiving 
task. A DECnet-20 target task can then use the SIN and BIN (read 
data) monitor calls (see Section 4.1.2) to retrieve as many bytes at a 
time as it can handle in its data buffer. Normally, you would include 
a count byte at the beginning of each logical data group to provide 
the receiving task with a means to reconstruct the logical data. 

You can also intermix the use of SOUT and SOUTR when you send data to 
a receiving task. For example, assume that you are programming a task 
with a data buffer limited to 300 bytes. The receiving task has a 
1000 byte buffer and requires that data be sent to it in logical 
message format. You can send an 800 byte logical message by sending 
two SOUTs for 300 bytes each followed by a SOUTR for 200 bytes. The 
receiving task can then retrieve the entire message by using a SINR 
for 800 bytes or more. 
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4.1.2 Receiving Data 

You can retrieve data from the network using the SINR, SIN, or BIN 
monitor calls. In general, use SINR to retrieve logical messages and 
SIN to retrieve data from a continuous byte stream. 

The exclusive use of SINR usually implies that both you and the other 
task have agreed to exchange information in the form of messages with 
some stated maximum length. Each SINR monitor call results in the 
retrieval of one logical message. The sending task must have sent the 
message using the SOUTR monitor call (see Section 4.1.1). 

The exclusive use of SIN usually implies that both you and the other 
task have agreed to exchange information in the form of a continuous 
byte stream. You can retrieve as many bytes at a time as your data 
buffer can handle. If your data buffer is 300 bytes in length, you 
can execute a SIN for 300 bytes and fill the buffer with data. The 
manner in which you then reconstruct the original logical messages 
depends on the user-level protocol agreed to by both tasks. For 
example, if each message is preceded by a count byte, you can use the 
BIN monitor call to read the first byte and obtain the number of bytes 
in the message and then issue a SIN for that number of bytes to 
retrieve the message. A subsequent BIN would read the number of bytes 
in the next message. 

You can intermix the use of SIN and SINR when you wish to retrieve 
data from the network. However, a few precautions are in order. A 
SIN monitor call does not recognize an end-of-message indicator if one 
is present. Therefore, if you issue a SIN for 300 bytes and the link 
buffer contained the last 200 bytes of a logical message (sent with a 
SOUTR) , you will retrieve those 200 bytes plus the first 100 bytes of 
the next message. The SIBE monitor call is useful here because it 
will return the number of bytes of the current message that are 
available in the link buffer. You can then issue a SIN for that 
number of bytes and not encroach on the succeeding message. 

The SIBE monitor call should also be used just prior to dismissing a 
data available interrupt; this is to ensure that you have read all 
input currently in the buffer. Failure to test for an empty buffer 
can result in loss of a data interrupt. If data from the network 
arrives while the program is at interrupt level, no interrupt is given 
because the program has not yet dismissed the first interrupt. SIBE 
should always precede DEBRK to ensure no data is lost. 



4.2 TRANSFERRING INTERRUPT MESSAGES 

Although data transfers over a logical link are guaranteed to be 
received at the other end in the same order in which they were sent, 
it is occasionally necessary to bypass the normal flow of data and to 
send data that is to be delivered immediately. Events such as errors 
or status changes in one task or the other are situations that justify 
bypassing the normal data flow. 
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The logical link management level, NSP 
and reception of short high-prior 
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icators and usually require the 
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4.2.1 Sending Interrupt Messages 

A network task communicating over a logical link can initiate an 
interrupt message at any time. Whether DECnet-20 will send the 
message over the link depends on conditions at the other end. If the 
task at the other end has not acknowledged a previous interrupt 
message, the sending task is notified via an error message. If the 
other task is not enabled for interrupt messages, the link will not 
accept the message. 

To send an interrupt message, use the .MOSIM function of the MTOPR 
monitor call. 



The calling sequence expects the following: 



AC1 
AC 2 
AC 3 
AC 4 



The JFN of the logical link 

.MOSIM (function code) 

A byte pointer to the message 

The count of bytes in the interrupt message. The maximum 
message length is 16 bytes. 



Example 

The following program segment can be used to send an interrupt message 
to another task: 



SNDMSG: MOVE T1,NETJFN 

MOVE I T2,. MOSIM 

HRROI T3,MSG 

MOVEI T4,"D14 
MTOPR 

ERJMP JSYSXX 



GET NETWORK JFN 
SET UP FUNCTION 
POINTER TO MESSAGE 
BYTE COUNT 
ISSUE THE CALL 
JSYS ERROR 



MSG: 



ASCIZ /CLOSING AT 6PM/ 
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4.2.2 Receiving Interrupt Messages 

If the protocol used by network tasks includes interrupt messages/ 
each task should provide a way to be asynchronously notified of the 
messages 1 arrival. The .MOACN function of the MTOPR monitor call 
allows a network task to enable specific channels for software 
interrupts (see Section 3.3). One of these interrupts signals the 
arrival of an interrupt message. 

When a remote task sends your task an interrupt message, the 
appropriate channel presents a software interrupt to your task. To 
read the interrupt message, use the .MORIM function of the MTOPR 
monitor call. 

The calling sequence expects the following: 

AC1: The JFN of the logical link 



AC2: .MORIM (function code) 

AC3: A byte pointer to the receiving 
message length is 16 bytes. 



buffer . 



The maximum 



The call returns with an updated pointer in AC3, the message stored in 
the buffer, and the count of bytes received in AC4. 

Because interrupt messages are used to signal important asynchronous 
events, it is recommended that a task receiving an interrupt message 
read the interrupt message promptly. Furthermore, DECnet-20 does not 
acknowledge an interrupt message until the task reads it. This means 
that each network task is limited to one outstanding interrupt message 
and until that one is read, no others will be accepted. 



Example 

The following program segment retrieves an interrupt message: 



INTRPT: MOVE 
MOVE I 
MOVE 
MTOPR 
ERJMP JSYSXX 



T1,NETJFN 
T2,. MORIM 
T3, [POINT 8,MSGBUF] 



GET NETWORK JFN 
SET UP FUNCTION 
POINTER TO MESSAGE 
ISSUE THE CALL 
JSYS ERROR 



MSGBUF: BLOCK 



;MESSAGE BUFFER 



Figures 5-1 and 5-2 are examples, in program context, of some 
programming sequences described in this chapter. 



of the 
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A network connection can be closed by either of the two connected 
tasks. A connection can be closed normally, thereby preserving the 
integrity of any data in transit; or, a connection can be aborted 
without regard to any undelivered data. 



5.1 CLOSING A CONNECTION NORMALLY 

A normal close is usually accomplished with the CLOSF monitor call 
specifying a network JFN in AC1. The CZ%ABT bit in AC1 must be off. 
All buffered data that is in transit at the time is delivered (unless 
the remote task executes an abort before the CLOSF has completed) . 
The network JFN is then closed. 

An MTOPR call with function code .MOCLZ also disconnects the logical 
link and completes the delivery of all buffered data; however, it 
does not close the JFN. This method of closing a link is only used if 
it is necessary to send user data (up to 16 bytes) to the remote task. 
In order to send user data and also close the JFN, the .MOCLZ function 
must be followed by a CLOSF call. 

The calling sequence for the MTOPR call is: 

AC1: The JFN of the logical link 

AC2: in the left half and .MOCLZ in the right half 

AC3: A byte pointer to the user data. If the byte size is 
over 8, bytes are truncated to eight bits. 

AC4: The count of bytes in the user data. The maximum is 16 
bytes. 

The network does not have explicit protocol for a normal close. That 
is, no one specific network control message is available to both 
disconnect a logical link and also automatically have all data 
correctly delivered. When you use the MTOPR or CLOSF monitor call to 
close a network connection, you are actually turning over control of 
the link to the local NSP. It is the job of the local NSP to ensure 
that all outstanding data packets have been properly acknowledged 
before sending the disconnect message to the remote NSP. 

The remote NSP, in turn, notifies the remote task according to the 
protocol in effect at the remote node. 
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If the remote node is a DECnet-20 node, the NSP task receiving the 
disconnect message sets the MO%SYN bit in the remote task's link 
status to reflect that the link has been closed normally. If the 
remote task is not in the process of reading data, it is issued a data 
interrupt. If the remote task issues a SIBE call, it will be informed 
that no bytes are available. If the remote task attempts to read 
data, it will receive an end-of-file indication. In any case, reading 
the link status via the . MORLS function of MTOPR will indicate that 
the MO%SYN bit has been set. 



Example 

To close a logical link after delivering all the data 
transit, use a program segment such as the following: 



currently in 



CLOSE: MOVE 
CLOSF 
ERJMP 



T1,NETJFN 



JSYSXX 



GET NETWORK JFN 
ISSUE THE CALL 
JSYS ERROR 



To close a logical link as above and also include ASCII user data for 
the target task, a program segment such as the following can be used: 



CLOSED: MOVE 
MOVE I 
MOVE 
MOVE I 
MTOPR 

ERJMP 
CLOSF 
ERJMP 



T1,NETJFN 

T2, .MOCLZ 

T3, [POINT 7,MSG] 

T4,~D14 

JSYSXX 

JSYSXX 



GET NETWORK JFN 
SET UP FUNCTION 
POINTER TO MESSAGE 
BYTE COUNT 
ISSUE THE CALL 
JSYS ERROR 
CLOSE THE JFN 
JSYS ERROR 



MSG: 



ASCIZ /BE BACK AT 6PM/ 



;USER DATA 



5.2 ABORTING A CONNECTION 

You can abort a logical link with the CLOSF monitor call by specifying 
both the CZ%ABT bit and the network JFN in AC1. All buffered data in 
transit is discarded and the network JFN is closed. This operation 
can result in the loss of data and should only be used in a fatal 
error condition. 

The .MOCLZ function of MTOPR, used to normally close a logical link in 
Section 5.1, can be used to abort a logical link if you insert a 
nonzero code in the left half of AC2. This method of aborting a link 
should only be used if it is necessary to send the remote task a 
specific reason code for the abort, up to 16 bytes of user data, or 
both. The .MOCLZ function with the abort option discards all buffered 
data in transit and closes the link; however, it does not close the 
network JFN. To close the JFN, the MTOPR call must be followed by a 
CLOSF call with the CZ%ABT bit set in AC1. 
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The calling sequence for the MTOPR call is: 
AC1: The JFN of the logical link 



.MOCLZ in the 



AC2: A reason code, nn, in the left half and 
right half 

AC3: A byte pointer to the user data 

AC4: The count of bytes in the user data. The maximum is 16 
bytes 

The reason code (nn) in the left half of AC2 is one of the nonzero 
codes listed in Appendix A. 

With either the CLOSF or MTOPR monitor call, the local NSP sends a 
disconnect message to the remote NSP which, in turn, notifies the 
remote task according to some established protocol. 

If the remote node is a DECnet-20 node, the NSP task receiving the 
disconnect message sets the MO%ABT bit in the remote task's link 
status to reflect that the link has been aborted. If the remote task 
is not in the process of reading data, it is issued a data interrupt. 
Any attempts to read data will result in an I/O error. Reading the 
link status via the .MORLS function of MTOPR will indicate that the 
MO%ABT bit has been set and the right half of AC3 will contain a 
disconnect code if one was given. 



Example 

To abort a logical link immediately without completing the delivery of 
any data in transit, use a program segment such as the following: 



ABORT: MOVE 
TLO 
CLOSF 
ERJMP 



T1,NETJFN 
Tl, (CZ%ABT) 

JSYSXX 



GET NETWORK JFN 
SET ABORT BIT 
ISSUE THE CALL 
JSYS ERROR 



To abort a logical link as above and also include a specific reason 
code and user data, use a program segment such as the following: 



ABORTD: 



MOVE 
MOVE I 
HRLI 
MOVE 
MOVE I 
MTOPR 

ERJMP 
TLO 
CLOSF 

ERJMP 



T1,NETJFN 

T2, .MOCLZ 

T2, .DCX9 

T3, [POINT 7,MSGX] 

T4,~D16 

JSYSXX 

Tl, (CZ%ABT) 

JSYSXX 



GET NETWORK JFN 
SET UP FUNCTION 
CODE FOR USER ABORT 
POINTER TO MESSAGE 
BYTE COUNT 
ISSUE THE CALL 
JSYS ERROR 
SET ABORT BIT 
CLOSE THE JFN 
JSYS ERROR 



MSGX: ASCIZ /RESTART XMISSION/ 



;USER DATA 
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If the target task has the MO%ABT bit set in the link status word, the 
target task must use CZ%ABT or the CLOSF will fail. An example of a 
program segment using CZ%ABT follows: 



MOVE 


T1,NETJFN 


CLOSF 




ERJMP 


[ MOVE Tl,NETJFN 




TLO T1,(CZ%ABT) 




CLOSF 




JRST JSYSXX 




JRST .+1] 



;If fail, then 
;use CZ%ABT 



5.3 SOURCE AND TARGET TASK CODING EXAMPLES 

Figures 5-1 and 5-2 are examples of coding for source and target 
programs, respectively. The examples present, in context, many of the 
program segments given as examples in Chapters 3, 4, and 5. The 
examples are not complete programs that can be executed. 
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; Get JFN for Network Connection 

MOVX T1,GJ%SHT 

HRROI T2, [ASCIZ/DCN:NODEA-TASK-TARGET. SOURCE/] 

GTJFN 

ERJMP NOGOOD ;Failed, Probably out of resources 

MOVEM Tl,OURJFN ;Successful, save our JFN 

OPENF to create the Logical Link 

MOVX T2,<FLD(~D7,OF%BSZ)+OF%WR+OF%RD> ;Open for read and 

; write 
OPENF 
ERJMP NOGOOD ; Failed 

Wait for network connect to succeed or fail 

CHKST: MOVX T1,~D1000 ;Wait before checking status 
DISMS 

MOVE Tl,OURJFN ;Check link status 

MOVX T2,.M0RLS 
MTOPR 

ERJMP NOGOOD 

TXNE T3,MO%CON ;Connected? 

JRST HELLO ;Yes, proceed to HELLO 

TXNE T3,M0%WCC ;No, are we waiting still? 

JRST CHKST ;Yes, delay some more 
; If we get here, target process or network rejected cannot attempt- 

JRST NOGOOD ;We lose 

Send data to Target task 

HELLO: MOVE Tl,OURJFN 

HRROI T2, [ASCIZ/Hello Target! 

/] 

SETZM T3 
SOUTR 
ERJMP NOGOOD ; Network went away 

CLOSF to disconnect logical link 

MOVE Tl,OURJFN 
CLOSF 
ERJMP [ MOVE Tl,OURJFN ;Failed, use CZ%ABT 
TXO T1,CZ%ABT ; to close link 
CLOSF 

JFCL ;Don't Care if it fails 

JRST .+1] 
HALTF ;Stop source task 

Include what you wish to do on failure of logical link 

NOGOOD: . 

OURJFN: BLOCK 1 



Figure 5-1 Example of Source Task Coding 
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Get JFN for Network Connection 

START: MOVX Tl,GJ%SHT 

HRROI 12, [ASCIZ/SRV: .TARGET/] 
GTJFN 

ERJMP NOGOOD ;Failed, Probably out of resources 

MOVEM Tl,OURJFN ;Successful, save our JFN 

Start setting up interrupt system for network JFN 

MOVX T1,.FHSLF ;Set up interrupt system first 

MOVE T2 , [ LEVTAB , , CHNTAB ] 

SIR ;Set interrupt system tables 

MOVX T2,3B1 ; Enable channels and 1 

AIC ;Activate interrupt channels 

EIR ;Enable for interrupts 

OPENF to make us available to the network 

MOVX T2,<FLD(~D7,OF%BSZ)+OF%WR+OF%RD> ;Open for read and 

;wr ite 
OPENF 
ERJMP NOGOOD ; Failed 

Finish setting up interrupt system for network JFN 

MOVE Tl,OURJFN ;Set up Connect and Data Interrupts 

MOVE I T2,.MOACN 

MOVX T3, <FLD(0 f MO%CDN) +FLD ( 1 ,MO%DAV) +FLD( . MONCI ,MO%INA) > 

MTOPR 

PAUSE: WAIT ;Wait for Interrupts 

LEVTAB: PC ; Level 1 PC address 





CHNTAB: 1,, HELLO ;On connect go to HELLO 

1,,READIT ;On data interrupt try to read it 

REPEAT ~D34,<0> ;Zero fill rest of table 

PC: BLOCK 1 ;Level 1 PC save location 

Process interrupt on Connect channel 

HELLO: MOVE T1,0UPJFN ;Always accept the connection 

MOVX T2,.M0CC 

SETZB T3,T4 ;No optional data 
MTOPR 

ERJMP NOGOOD ; Something blew up 

DEBRK ;Done, wait some more 

Figure 5-2 Example of Target Task Coding 
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Process interrupt on Data channel 



READIT: MOVE 
SIBE 



Tl,OURJFN 



JRST READ 

MOVX T2,.MORLS 
MTOPR 

ERJMP NOGOOD 

TXNN T3,MO%CON 

JRST DISCON 
DEBRK 

READ: HRROI T2, BUFFER 

MOVNI T3,~D1000 
SINR 

ERJMP NOGOOD 

SETZM Tl 

IDPB T1,T2 

HRROI Tl, BUFFER 
PSOUT 

JRST READIT 



Any data? 

Yes, Process it 

No, See if link still connected 

An error here is not likely, but... 

Link Still Connected? 

No, process link down 

Yes, then wait for another interrupt 

Put data into buffer 
- Size of buffer 
Read the data 
Shouldn't happen 
Store a zero byte 



;Output the message 
;Process any more input 



;Close our JFN 

;Try CLOSF with CZ%ABT 



Process disconnect on link 

DISCON: MOVE Tl,OURJFN 
CLOSF 
ERJMP [ MOVE Tl,OURJFN 
TXO T1,CZ%ABT 
CLOSF 

JFCL ;Don't care if it fails 
JRST .+1] 
JRST START ; Start over 

Include what you wish to do on failure 

NOGOOD: . 



BUFFER: BLOCK 
OURJFN: BLOCK 



D1000 



:Buffer save location 
;OURJFN save location 



Figure 5-2 (Cont.) Example of Target Task Coding 
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PART III 



OPERATOR'S GUIDE 



CHAPTER 6 
RUNNING DECnet-20 



The Operator Command Language program/ OPR, provides the operator with 
one command language to communicate with several TOPS-20 components, 
including the DECnet-20 control program, NETCON. OPR identifies 
commands to NETCON when you type "NCP" (Network Control Program) . You 
may type NCP followed by the NCP command as shown below: 

$OPR 

OPR>NCP SHOW STATUS LOCAL 

OPR> 

08:18:33 NCP request # 5 [SHOW STATUS LOCAL] 

Status of local node as of 17-May-79 08:18:33 

Node Name is 2102, # 64, System = 2102 Development System, 

TOPS-20 

Routing Version = 3.0.0, Communications Version = 3.0.0 

State is On, Default Host = Unknown 

Function Completed Successfully 



or, you may ENTER NCP as shown below: 



OPR>ENTER NCP 

NCP>SHOW STATUS LOCAL 

NCP> 

08:19:10 NCP request # 6 [SHOW STATUS LOCAL] 

Status of local node as of 17-May-79 08:19:10 

Node Name is 2102, # 64, System = 2102 Development System, 

TOPS-20 

Routing Version = 3.0.0, Communications Version = 3.0.0 

State is on, Default Host = Unknown 

Function Completed Successfully 

NCP> 
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OPR processes NCP commands for syntax only (for correct format and 
presence of required keywords, for example). Commands that are 
syntactically acceptable are passed by OPR to ORION, the operator 
control program. ORION, in turn, forwards the NCP commands to NETCON, 
the program that controls the processing and execution of NCP 
commands. Specifically, it is the NCP (processing) module of NETCON 
that receives the commands from ORION. When processing is complete, 
the NCP module passes all but the simplest commands to the NICE module 
on the executor node. Unless changed using the SET EXECUTOR command, 
the executor node will be the node where NETCON is running. 



6.1 THE NETWORK CONTROL PROGRAM 

DECnet-20 operations are controlled by the TOPS-20 program called 
NETCON. NETCON exists only as an executable file, NETCON.EXE. The 
control file and the three major source programs used in building 
NETCON are on the DECnet-20 distribution tape as NETCON. CTL, 
NETPAR.MAC, NCP. MAC, and NCU.MAC, respectively. Within the NETCON 
program, command processing is accomplished by the NCP module; 
command execution is accomplished by the NCP module or the NICE 
module, sometimes referred to as the Network Control Utility (NCU) . 
As an operator you interact with NCP through OPR. The NCP module 
interacts with the NICE module. 

NCP commands are directed: 

• To the NETCON program itself 

(an example would be the SHOW EXECUTOR command) 

• To the network 

(an example would be the LOAD REMOTE command) 

• To a specific operating system and executed locally 

(an example would be SET LOCAL LOOPBACK ENABLED command) 

It is the commands directed to the network that require the use of the 
Network Information and Control Exchange (NICE) protocol implemented 
in the NICE (NCU) module of NETCON. Through the use of a common 
protocol, NICE, the user is relieved of all concern with differences 
in implementations among the various families of DIGITAL computers. 
Any node that is a member of a given network can access the 
information and control facilities of a remote node on the same 
network if the following conditions are met: 

• The node owning the information or facilities permits access 

• The node owning the information or facilities has implemented 
the required NICE function 

If a remote node is not able to honor a request, the system responds 
"? Request failed," followed by a message. A complete list of NCP 
command responses is given in Section 6.5.1. 
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Examples: 



NCP>LOOP LINE KDP_0_0 

NCP> 

15:36:10 NCP request # 11 [LOOP LINE KDP _ _ 0] 

? Request failed, Invalid function or option 

(The current executor was the host node. 
Before the LOOP LINE command, the user should 
have given the command SET EXECUTOR with the 
node name of the DECnet-20 communications front 
end. ) 

***** 

NCP>SHO COU LIN DTE_1 
NCP> 

15:23:41 NCP request # 8 [SHOW COUNTS LINE DTE20 _ 1] 

? Request failed, Insufficient status 

(The line id should have been a valid lineid on 
the executor node.) 



Not all DECnet systems implement all possible functions. Note that 
communication is still possible within the restrictions of the set of 
commands implemented by the remote node. You can refer to the manuals 
specific to the operating systems of the nodes in your network to 
determine the capabilities of their operating systems. (Within 
operating systems further restrictions are possible due to 
insufficient memory.) 

At the network planning level, the system manager may find it 
advisable to limit some of the available NCP commands to specific 
privileged users or groups. 

The tasks that NETCON performs on any given system depends on the 
configuration of the specific system. Given the device drivers and 
optional hardware required, NETCON can perform the following tasks. 

For the DECSYSTEM-2020, NETCON can: 

• Load a synchronous line controller 

• Dump a synchronous line controller 

• Control the state of a synchronous line 

• Display the status of NCP requests 

• Display line status and activity 

• Control the logging of network events and line counters in the 
SYSERR file 

• Start a line in cable-loopback or controller-loopback mode 
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For the DECSYSTEM-2040 , 2050, 2060, NETCON can: 

• Set up the load and dump parameters for the communications 
front end 

• Set up the load and dump parameters for a remote job entry 
station 

• Load a communications front end 
| • Load a remote job entry station 

• Dump a communications front end 
| • Dump a remote job entry station 

• Display the status of NCP requests 

• Display line status and activity 

• Control the logging of network events and line counters in the 
SYSERR file 

• Turn event/error logging ON/OFF at either the line level (line 
drivers logging messages to NICE) or the NICE level 
(forwarding of messages to host) 

• Perform loopback test on designated line 

• Define an adjacent node other than the host node as the node 
that will load or dump a target node 

• Specify the protocol to be used by the communicating nodes 



6.2 DECnet-20 STARTUP PROCEDURES 

The procedure for loading and starting DECnet-20 depends on the model 
of the DECSYSTEM-20. 

On the DECSYSTEM-2040, 2050, 2060, there is a communications front-end 
processor that must be loaded. This occurs automatically when TOPS-20 
is loaded or it can be performed manually at any time after TOPS-20 is 
loaded . 

On the DECSYSTEM-2020, there is no separate DECnet-20 communications 
front-end processor to be loaded. The standard DECSYSTEM-2020 monitor 
supports DECnet. Therefore, whenever you load TOPS-20, you are also 
automatically loading DECnet-20 support code and support for the 
synchronous line controller. 



6.2.1 Automatic Startup on a DECSYSTEM-2020 

The automatic startup of DECnet-20 on a DECSYSTEM-2020 is merely a 
function of loading the TOPS-20 monitor. The DECnet code is 
integrated with the TOPS-20 code. Figure 6-1 is a sample of what you 
might see when bringing up TOPS-20 with DECnet-20 on a DECSYSTEM-2020. 
Note that the ORION program runs under SYSJOB, the NETCON program runs 
as a separate job, and the OPR sub job runs under PTYCON. 
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(Mount the PS: disk pack on drive 0. Then press the BOOT button on 
the DECSYSTEM-2020 control panel.) 

BT SW 

[PS MOUNTED] 

System restarting, wait... 

ENTER CURRENT DATE AND TIME: 10-OCT-79 900 

YOU HAVE ENTERED WEDNESDAY, 10-OCTOBER-1979 9:00AM, 

IS THIS CORRECT (Y,N) Y 
WHY RELOAD? T/S 

RUN CHECKD? N 

RUNNING DDMP 

SYSJOB 4(10) STARTED AT 10-OCT-79 0900 

RUN SYS: ORION 

RUN SYS: QUASAR 

RUN SYS:MOUNTR 

RUN SYS: INFO 

RUN SYS: MAILER 

RUN SYS: MAPPER 

RUN SYS:LPTSPL 

RUN SYS:CDRIVE 

RUN SYS: SPRINT 

RUN SYS:FAL 

JOB /LOG OPERATOR XX OPERATOR 

ENA 

"ESET LOGIN PSEUDO 

"ESET LOGIN CONSOLE 

~ESET OPERATOR 

PTYCON 

GET SYSTEM: PTYCON. ATO 

/ 

JOB 1 /LOG OPERATOR XX OPERATOR 

ENA 

RUN SYS:BATCON 

/ 

JOB 2 /LOG OPERATOR XX OPERATOR 

ENA 

RUN SYS:NETCON 

/ 

Figure 6-1 Startup Dialogue for TOPS-20 DECnet-20 on a 

DECSYSTEM-2020 
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10/10-INSTALLATION-TEST SYSTEM, TOPS-20 MONITOR 4(3100) 
10/10-INSTALLATION-TEST SYSTEM, TOPS-20 MONITOR 4(3100) 
10/10-INSTALLATION-TEST SYSTEM, TOPS-20 MONITOR 4(3100) 

@LOG OPERATOR OPERATOR 

@LOG OPERATOR OPERATOR 

@LOG OPERATOR OPERATOR 
JOB 1 ON TTY43 10-OCT-79 09:00:42 

@ENA 
JOB 2 ON TTY44 10-OCT-79 09:00:42 
JOB 3 ON TTY45 10-OCT-79 09:00:43 

$"ESET LOGIN PSEUDO 

@ENA 

$"ESET LOGIN CONSOLE 

$RUN SYS:BATCON 

$"ESET OPERATOR 

$PTYCON 

PTYCON> GET SYSTEM: PTYCON.ATO 

PTYCON>SILENCE 

@ENA 

$RUN SYS:NETCON 



[From OPERATOR on line 45: SYSTEM IN OPERATION] 

SJ 0: PTYCON.LOG. 1 

SJ 0: PTYCON> W ALL 

SJ 0: OPR(0) 3 OPERATOR OPR 

SJ 0: PTYCON> CONN OPR 

SJ 0: [CONNECTED TO SUBJOB OPR(0)] 



TI 



0:0:6 



Figure 6-1 (Cont.) 



Startup Dialogue for TOPS-20 DECnet-20 on a 
DECSYSTEM-2020 
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6.2.2 Automatic Startup on a DECSYSTEM-2040, 2050, 2060 

On a DECSYSTEM-2040, 2050, 2060, the automatic startup of DECnet-20 
involves a number of related operations. 

One of the first programs executed when TOPS-20 is loaded is SYSJOB, a 
system process that starts up other system processes. SYSJOB executes 
the command file PS: <SYSTEM>SYSJOB.RUN. You edit this file to include 
startup commands for the NETCON program (see Chapter 10) . NETCON has 
already been described at the beginning of this chapter. ORION is the 
operator's interface to NETCON. Network commands from the operator 
are parsed by the operator command parser (OPR) and then passed to 
ORION which, in turn, forwards them to NETCON. 

The SYSJOB. RUN file also starts a PTYCON job and executes the 
PTYCON.ATO command file. In Chapter 10, the PTYCON. ATO file is edited 
to include starting the subjob OPR. OPR, in turn, executes the 
NCP.CMD file which sets up the DECnet-20 data base and loads the 
communications front-end. Figure 6-2 is an example of a startup 
dialogue for bringing up TOPS-20 with DECnet-20 on a DECSYSTEM 2040, 
2050, or 2060. The example is taken from an operating system running 
TOPS-20 Version 4 with DECnet Version 2, including the RJE option. 
Prior to the example, the procedures you will follow in Chapters 9 and 
10 (DECnet configuration, installation, and acceptance) have been 
accomplished. Startup procedures for your system may show differences 
according to your site's hardware and software; for example, the 
availability of extended addressing and cache memory hardware depends 
on the model selected for your site. 



6-7 



RUNNING DECnet-20 

(Mount the PS: disk pack on drive 0. Then, press the ENABLE rocker 
switch while pressing the DISK rocker switch on the console front 
end. ) 

RSX-20F YB13-41 6:34 21-SEP-79 

[SYO: REDIRECTED TO DBO:] 

[DBO: MOUNTED] 

KLI — VERSION VB12-12 RUNNING 

KLI — KL10 S/N: 2136., MODEL B, 60 HERTZ 

KLI — KL10 HARDWARE ENVIRONMENT: 
MOS MASTER OSCILLATOR 

EXTENDED ADDRESSING (Note: Extended addressing 

INTERNAL CHANNELS is a Model B feature only.) 

CACHE (Note: Cache memory is available 

only on DECSYSTEMs-2050/2060 . ) 

KLI — MICROCODE VERSION 231 LOADED 

KLI — ALL CACHES ENABLED 

LOGICAL MEMORY CONFIGURATION. 

ADDRESS SIZE INT TYPE CONTROLLER 
000000000 128K 4 MA20 0_1 
004000000 768K 4 MF20 11 

KLI — CONFIGURATION FILE WRITTEN 
KLI — BOOTSTRAP LOADED AND STARTED 

[PS MOUNTED] 

System restarting, wait... 

ENTER CURRENT DATE AND TIME: 9-OCT-79 1204 

YOU HAVE ENTERED TUESDAY, 9-OCTOBER-1979 12: 04PM, 

IS THIS CORRECT (Y,N) Y 
WHY RELOAD? T/S 

RUN CHECKD? N 

RUNNING DDMP 

SYSJOB 4(10) STARTED AT 9-OCT-79 1204 
RUN SYS: ORION 
RUN SYS: QUASAR 

***** 

9-OCT-79 12:04:39 - TGHA V2 IS RUNNING FOR THE FIRST TIME. 
***** 

RUN SYS:MOUNTR 

RUN SYS: INFO 

RUN SYS:MAILER 

RUN SYS: MAPPER 

RUN SYS:LPTSPL (Note: this example shows that 

RUN SYS:LPTSPL three line printer spoolers are 

RUN SYS:LPTSPL controlled by this system's 

RUN SYS:CDRIVE monitor — one for RJE station.) 

RUN SYS: SPRINT 

RUN SYS:FAL 

Figure 6-2 Startup Dialogue for TOPS-20 DECnet-20 on a 
DECSYSTEM-2040, 2050, 2060 
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JOB /LOG OPERATOR XX OPERATOR 

ENA 

"ESET LOGIN PSEUDO 

"ESET LOGIN CONSOLE 



ESET OPERATOR 

PTYCON 

GET SYSTEM: PTYCON. ATO 

/ 

JOB 1 /LOG OPERATOR XX OPERATOR 

ENA 

RUN SYS:BATCON 

/ 

JOB 2 /LOG OPERATOR XX OPERATOR 

ENA 

RUN SYS:NETCON 

/ 

SJ 

10/9-INSTALLATION-TEST SYSTEM, TOPS-20 MONITOR 4(3117) 

10/9-INSTALLATION-TEST SYSTEM, TOPS-20 MONITOR 4(3117) 

10/9-INSTALLATION-TEST SYSTEM, TOPS-20 MONITOR 4(3117) 



@LOG OPERATOR OPERATOR 
@LOG OPERATOR OPERATOR 
@LOG OPERATOR OPERATOR 
JOB 2 ON TTY207 9-OCT-79 12:04:51 



SJ 





SJ 


1 


SJ 


1 


SJ 
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1 
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1 


SJ 





SJ 





SJ 


n 


SJ 






ON TTY206 9-OCT-79 12:04:52 
ON TTY205 9-OCT-79 12:04:53 



JOB 1 

JOB 3 
@ENA 
@ENA 
@ENA 

$RUN SYS:NETCON 
$RUN SYS:BATCON 
$~ESET LOGIN PSEUDO 
$"ESET LOGIN CONSOLE 
$"ESET OPERATOR 
$ PTYCON 

PTYCON > GET SYSTEM: PTYCON. ATO 
PTYCON> SILENCE 



[From OPERATOR on line 210: SYSTEM IN OPERATION] 

SJ 0: PTYCON.LOG. 1 

0: PTYCON> W ALL 

0: OPR(0) 3 OPERATOR OPR 

0: PTYCON> CONN OPR 

0: [CONNECTED TO SUBJOB OPR(0)] 

2: 0:29:45 NCP REQUEST 



SJ 
SJ 
SJ 
SJ 
SJ 
SJ 



TI 



0:0:1 



2: 



1 [LOAD NODE DN20A] 
FUNCTION COMPLETED SUCCESSFULLY 



Figure 6-2 (Cont. 



Startup Dialogue for TOPS-20 DECnet-20 on a 
DECSYSTEM-2040, 2050, 2060 
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6.2.3 Manual Startup on a DECSYSTEM-2020 

To manually start DECnet-20 on a DECSYSTEM-2020, you must load the 
KMC11 line controller with the file COMIOP.KMC. This file was 
restored to the directory <SUBSYS> from the DECnet-20 distribution 
tape during the installation procedure in Chapter 10. From an enabled 
TOPS-20 prompt, enter the following dialogue: 

$OPR ( KhT ) 

OPR> ENTER NCPGED 

NCP>LOAD CONTROLLER KDP_0 FROM PS : <SUBSYS>COMIOP . KMCQID 

NCP>EXITQiD 

$ 



6.2.4 Manual Startup on a DECSYSTEM-2040, 2050, 2060 

To manually start DECnet-20 on a DECSYSTEM-2040, 2050, 2060, you must 
load the communications front end with DECnet-20 software. The 
following sequence of commands identifies the load and dump files, 
loads the front end, and starts logging line statistics. From an 
enabled TOPS-20 prompt, enter the following dialogue: 

$0PRQiED 

OPR> ENTER NCPQiD 

NCP>SET EXECUTOR hostnodename C km ) 

NCP>SET SECONDARY-LOAD-FILE DTE20 PDP-11 PS : <SUBSYS>DTEMPS . BINC^I 

NCP>SET TERTIARY-LOAD-FILE DTE20 PDP-11 PS : <SUBSYS>DTEMPT . BIN( 

NCP>SET NODE nodename SERVER servername DTE20_1(_!U_l) 

NCP>SET NODE nodename PROTOCOL-TYPE NETWORK-SERVICES-PROTOCOL( 

NCP>SET NODE nodename LOAD-FILE PS: <SUBSYS>nodename . SYSQiD 

NCP>SET NODE nodename DUMP-FILE PS: <SUBSYS>nodename . DMP(jhl) 

NCP>LOAD NODE nodename (JED 

NCP> 

hh:mm:ss NCP REQUEST # n [LOAD NODE nodename] 

Function completed successfully 
NCP> INITIATE LOGGING LINE-COUNTERS KDP_0_0 nodenameQTT} 
NCP>EXITQiD 

$ 

where : 

hostnodename is the node name assigned to the main or central 
processor . 

nodename is the node name assigned to the communications front 
end. See Section 9.4, Configuring for Task-to-Task. 

servername is the node name assigned to the host processor. See 
the NODE command in the editing of the 4-CONFIG.CMD 
file in Chapter 10. 

NOTE 

If the front-end data base is intact and 

correct as set up during the loading of 

TOPS-20, you need only enter the LOAD 

NODE nodename command to start 
DECnet-20. 
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6.3 NCP COMMAND SUBSET OF OPR 

To use the NCP commands, you must first run the OPR program and access | 
the NCP subset of commands. In order to run OPR you should be 
ENABLEd ; if not, you will receive the following message: 

iaOPR ( »" ) 

10:31:42 — Insufficient Privileges Enabled — 

<a 

ENABLE before running OPR: 

@ENABLE (CAPABILITIES)GZD 

$OPRQtD 

OPR> ENTER (COMMAND SUBSET) NCPQED 
NCP> 

The NCP commands fall into three general categories: 

• Data base commands - to build or change the load, dump, 

operating, and logging parameters in 
a node's network data base. 

• Action commands - to load and dump nodes or lines, 

alter line states, control loopback 
testing, monitor network requests, 
and display line status and 
statistics. 

• Miscellaneous commands - to change the location of the NCP 

command processor, and to turn 
EVENT/ERROR logging on or off. 

Some NCP commands are system-dependent; in the following command 
descriptions, such commands are flagged with the appropriate model 
numbers. 

NOTE 

For compatibility with other DECnet 
systems, the keyword NODE in any NETCON 
command may be replaced with the keyword 
REMOTE. 

The table that follows is an alphabetized list of available NCP 
commands with their applicable keywords and arguments. See the 
description of each command for system-dependencies. 
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Table 6-1 
NCP Command Summary 



Command 


KEYWORDS and/or Arguments 


DISABLE 


EVENT-LOGGING 


(KNOWN LINES 1 
\LINE lineid) 














DUMP 


CONTROLLER 
NODE 


ctlrid filespec 
nodename [filespec] 






ENABLE 


EVENT-LOGGING 


/KNOWN LINES 1 
(LINE lineidl 














EXIT 










INITIATE 


LOGGING 


LINE-COUNTERS lineid 


nodename 




LOAD 


CONTROLLER 
NODE 


ctlrid filespec 
nodename [filespec] 




MIXED J 


*LOOP 


LINE 


lineid COUNT xx 


LENGTH yy WITH 


ZEROES) 
ONES J 


PUSH 










RETURN 










SET 


EXECUTOR 


nodename 








LOCAL 


LOOPBACK (ENABLED 
(DISABLED 


lineid 1 
lineid ) 












LOGGING- INTERVAL 


LINE-COUNTERS nminutes 








NODE 


nodename /AUTO-DUMP 


(ENABLED i 
(DISABLED) 


\ 






( 








1 AUTO-LOAD 


j ENABLED ( 

\disabled/ 








\ DUMP-FILE 


filespec 








J LOAD-FILE 


filespec 








f PROTOCOL-TYPE 


NETWORK-SERVICES-PROTOCOL 1 






V SERVER 


servernode lineid / 




SECONDARY-LOAD-FILE 


devtype cputype 


filespec 






STATE 


LINE lineid 


(CABLE-LOOPBACK 

I CONTROLLER-LOOPBACK 

! MAINTENANCE 

) ON 

\OFF 


) 
I 




TERTIARY-LOAD-FILE 


devtype cputype 


filespec 




SHOW 


COUNTS 
EXECUTOR 
QUEUE 
STATUS 


LINE lineid 
NCP-REQUESTS 

(known LINES ) 
^LINE lineid 
(LOCAL ) 














TAKE 




filespec 






TERMINATE 


LOGGING 


LINE-COUNTERS lineid 


nodename 





*The LOOP LINE command may contain any combination of the three 
keywords COUNT, LENGTH, and WITH. 
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6.3.1 Data Base Commands 



6.3.1.1 Defining the Bootstrap Programs (2040, 2050, 2060) - The 

following two commands specify the secondary and tertiary bootstrap 
programs to be used when a request to load a node is received. 

The format of the commands is: 

SET SECONDARY-LOAD-FILE devtype cputype filespec 
SET TERTIARY-LOAD-FILE devtype cputype filespec 

where : 

devtype specifies the type of line device (on the target node) over 
which NETCOM will be loading the bootstrap program. This 
can be the DTE20 or DMC11. 

cputype specifies the type of CPU the bootstrap program will be 
loaded into. This is the PDP-11. 

filespec specifies the appropriate secondary or tertiary bootstrap 
program to be loaded. 

If the node to be loaded is a communications front end, use the 
following commands: 

SET SECONDARY-LOAD-FILE DTE20 PDP-11 PS : <SUBSYS>DTEMPS . BIN 
SET TERTIARY-LOAD-FILE DTE20 PDP-11 PS : <SUBSYS>DTEMPT. BIN 

If the node to be loaded is a remote job entry station such as a 
DN200, use the following commands: 

SET SECONDARY-LOAD-FILE DMC11 PDP-11 PS : <SUBSYS>SECDMC . SYS 
SET TERTIARY-LOAD-FILE DMC11 PDP-11 PS : <SUBSYS>TERDMC . SYS 



6.3.1.2 Defining the Loading Node (2040, 2050, 2060) - The SET NODE 
SERVER command is used to specify the adjacent node that will perform 
the load or dump operation. 

The format of the SET NODE SERVER command is: 

SET NODE targetnode SERVER servernode serverlineid 

where : 

targetnode is the name of the node that will be loaded or 

dumped . 

servernode is the name of the node adjacent to the targetnode 

that will perform the loading or dumping. 
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serverlineid is the identification of the line or interface on 

the servernode that connects to the targetnode. The 
format of serverlineid is: 

dev_ctlr_unit 

where : 

dev is the type of device on the 

servernode that interfaces or 

connects to the targetnode. This 

can be DTE20, DMC11, DUP11, or KDP. 

(DUPlls are not supported for all 
configurations. ) 

(underscore) is a required separator character. 

ctlr is the number of the specific 

device controller. 

(underscore) is an optional separator character, 
required if unit is specified. 

unit is the specific line unit on a KDP 

device . 



6.3.1.3 Defining the Default Load File (2040, 2050, 2060) - The SET 

NODE LOAD-FILE command is used to specify the default load file for a 
node . 

The format of the SET NODE LOAD-FILE command is: 

SET NODE targetnode LOAD-FILE PS: <SUBSYS>targetnode .SYS 

where : 

targetnode is the name of the node that is to be loaded. 

6.3.1.4 Defining the Default Dump File (2040, 2050, 2060) - The SET 

NODE DUMP-FILE command is used to specify a default dump file for a 
node . 

The format of the SET NODE DUMP-FILE command is: 

SET NODE targetnode DUMP-FILE PS : <SUBSYS>targetnode .DMP 

where : 

targetnode is the name of the node that is to be dumped. 
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6.3.1.5 Defining the Protocol (2040, 2050, 2060) - The SET NODE 
PROTOCOL-TYPE command is used to specify the protocol to be followed 
by nodes when communicating. 

The format of the SET NODE PROTOCOL-TYPE command is: 

SET NODE targetnode PROTOCOL-TYPE protocoltype 

where : 

targetnode is the name of the node that is being loaded or 

dumped. 

protocoltype is the specific protocol to be followed by the 

target and server nodes when communicating. 

NOTE 

Version 2 of DECnet-20 restricts the 
following command variable as shown: 

protocoltype NETWORK-SERVICES-PROTOCOL 

RSX20F-QUEUED-PROTOCOL 
(Only NETWORK-SERVICES-PROTOCOL is 
currently supported.) 



6.3.1.6 Initiating Logging (all models) - The INITIATE LOGGING 
command is used to enable the periodic recording of line activity at a 
node. For a DECSYSTEM-2040/50/60 this command is restricted to the I 
DN20-side of the DTE. This means that the nodename parameter can not I 
be the host's node name. (See Section 6.3.2.4.) The line statistics | 
are requested by NETCON and are recorded in the form of SYSERR entries 
to the TOPS-20 ERROR. SYS file. SYSERR entries are described in detail 
in Appendix C. 

The format of the INITIATE LOGGING command is: 

INITIATE LOGGING LINE-COUNTERS (FOR LINE) lineid (ON NODE) nodename 

where: 

lineid identifies the line for which the statistics are being 
recorded. The format of lineid is: 

dev_ctlr_juni 

where : 

dev is the device type: DMC11, DUP11, KDP, or DTE20. | 

ctlr is the controller number. 

uni is the unit number. 

nodename is the name of the node at the particular end of the line 
being recorded. This means that a line may have its 
statistics reported from either end. 

Both lineid and nodename are required entries. 
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6.3.1.7 Terminating Logging (all models) - The TERMINATE LOGGING 
command is used to stop the recording of line activity at the 
specified line and node. 

The format of the TERMINATE LOGGING command is: 

TERMINATE LOGGING LINE-COUNTERS (FOR LINE) lineid (ON NODE) nodename 

See Section 6.3.1.6 for a definition of lineid and nodename. 

6.3.1.8 Setting Logging Interval (all models) - The SET 

LOGGING-INTERVAL command is used to specify how often NETCON will log 
line statistics. This interval applies to all lines enabled for 
logging. If this command is not given, the default interval is 60 
minutes. 

The format of the SET LOGGING-INTERVAL command is: 

SET LOGGING-INTERVAL (FOR) LINE-COUNTERS (TO) n (MINUTES) 

where : 

n is the number of minutes between requests for line counters. 



6.3.1.9 Enabling Local Loopback (2020) - The SET LOCAL LOOPBACK 
ENABLED command is used to inform the local NSP that a particular line 
is going to be operated in loopback mode. One effect of this is that 
data being exchanged over local logical links (connections between 
tasks on the same node) is not routed entirely in the software but is 
actually sent to the line controller. Whether the data is reflected 
in the controller itself or in the cable beyond is determined by the 
SET STATE LINE commands described in Sections 6.3.2.9 and 6.3.2.10. 

Another effect of the SET LOCAL LOOPBACK ENABLED command is that the 
local NSP now expects to receive a reflection of any node 
initialization message sent when the line is activated. 

The format of the SET LOCAL LOOPBACK ENABLED command is: 

SET LOCAL LOOPBACK ENABLED lineid 

where : 

lineid is a required entry and identifies the line to be operated 
in loopback mode. The format of lineid is described in 
Section 6.3.1.6. 



NOTE 

The line identified by lineid must be 
turned off before issuing this command. 
See the SET STATE LINE OFF command in 
Section 6.3.2.11. 
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6.3.1.10 Disabling Local Loopback (2020) - The SET LOCAL LOOPBACK I 

DISABLED command is used to inform the local NSP that a particular | 

line is no longer being operated in loopback mode. The effects of 

loopback operation described in Section 6.2.1.9 are no longer in 
effect . 

The format of the SET LOCAL LOOPBACK DISABLED command is: 

SET LOCAL LOOPBACK DISABLED lineid 

where : 

lineid is a required entry and identifies the line that is no 
longer in loopback mode. The format of lineid is described 
in Section 6.3.1.6. 

NOTE 

The line identified by lineid must be 
turned off before issuing this command. 
See the SET STATE LINE OFF command in 
Section 6.3.2.11. 



6.3.1.11 Controlling Automatic Reloading (2040,2050,2060) - The SET 
NODE AUTO-LOAD command controls whether or not the communications 
front end is automatically reloaded after a front-end crash. 

The format of the SET NODE AUTO-LOAD command is: 

SET NODE nodename AUTO-LOAD I ENABLED 

(DISABLED 

where : 

nodename identifies the DECnet-20 communications front end for 
which you are setting the autoload control. 

ENABLED causes the DECnet-20 communications front end to be 
automatically reloaded after a front-end crash. When 
the system is initially loaded, ENABLED is in effect. 

DISABLED causes the DECnet-20 communications front end not to be 
automatically reloaded after a front-end crash. 
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6.3.1.12 Controlling Automatic Dumping (2040,2050,2060) - The SET 

NODE AUTO-DUMP command controls whether or not the communications 
front end is automatically dumped after a front-end crash. 

The format of the SET NODE AUTO-DUMP command is: 

SET NODE nodename AUTO-DUMPJ ENABLED I 

(DISABLED j 

where : 

nodename identifies the communications front end for which you 
are setting the autodump control. 

ENABLED causes the communications front end to be automatically 
dumped after a front-end crash. When the system is 
initially loaded, ENABLED is in effect. 

DISABLED cause the communications front end not to be 
automatically dumped after a front-end crash. 



6.3.2 Action Commands 



6.3.2.1 Loading a Node (2040, 2050, 2060) - The LOAD NODE command 
loads and starts a target node with a specified or default program 
file. 

The format of the LOAD NODE command is: 

LOAD NODE targetnode [FROM (FILE) filespec] 

where : 

targetnode is the name of the node that is to be loaded. 

filespec is the file specification for the specific program to 
be loaded. If filespec is not included, the default 
load file specification defined in Section 6.3.1.3 is 
used. If neither file specification is specified, the 
system replies: 

REQUEST #n [LOAD NODE targetnode] 
CONFIGURATION DATA BASE ERROR 

where n is the NCP request number that NETCON assigned 
to the LOAD NODE command. 



NOTE 

Version 2 of DECnet-20 restricts the 
following command variable as shown: 

targetnode - the node name assigned to 
the communications front 
end. 
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6.3.2.2 Dumping a Node (2040, 2050, 2060) - The DUMP NODE command 
initiates a memory dump operation. 

The format of the DUMP NODE command is: 

DUMP NODE targetnode [TO filespec] 

where : 

targetnode is the name of the node that is to be dumped. 

filespec is the file specification for the dump file. If 
filespec is not included, the default dump file defined 
in Section 6.3.1.4 is used. 



NOTE 

Version 2 of DECnet-20 restricts the 
following command variable as shown: 

targetnode - the node name assigned to 
the communications front 
end . 

6.3.2.3 Checking NETCON's Request Queue (all models) - 

command checks NETCON's queue of network requests and displays both 

those that are currently in process and those not yet started. 

The format of the SHOW QUEUE command is: 

SHOW QUEUE (OF) NCP-REQUESTS 

The response will first list those requests that are in progress and 
then those not started yet, if any. 

hh :mm: ss 

NCP requests in progress: 

#3 - DUMP NODE DN2 
NCP requests on the queue but not yet started: 

#4 - LOAD NODE DN2 

If there are no outstanding requests, the response is: 
hh:mm:ss There are no outstanding NCP requests. 
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6.3.2.4 Displaying Line Statistics (all models) - The SHOW COUNTS 
command displays line statistics for a specified line. For a 
DECSYSTEM-2040/50/60, the capability of displaying line statistics is 
limited to the DN20. A request to display line statistics when the 
executor is the host node will receive an error response as described 
in Section 6.1. See Section 6.3.3.1 for details on changing the 
executor of a NETCON command. 

The format of the SHOW COUNTS command is: 

SHOW COUNTS LINE lineid 

where the format of lineid is the same as in Section 6.3.1.6. 

Assuming you are logged in at the host node (a DECSYSTEM-2050 , for 
example), the following is a possible example: 

NCP>SET EXECUTOR DN20A 

NCP>SHOW COUNTS LINE DMC11_1_0 

NCP> 

10:30:46 NCP request # 32 [SHOW COUNTS LINE DMC11_1_0] 

Counts for line DMC11_1_0_0, as of 5-Jun-79 10:30:45 

Seconds since zeroed 2488 

Blocks received 978 

Blocks sent 978 

Retran, line errors 3 

Received line errors 

Retran, not line errors 

Receive timeouts 3 

Function completed successfully 
NCP> 



6.3.2.5 Exiting from NCP Subset (all models) - The RETURN command 
returns you to operator command level, OPR>. Typing EXIT or CTRL/C to 
the OPR> prompt then returns you to TOPS-20 command level. If you 
wish, you may type a CTRL/C to the NCP> prompt and return directly to 
TOPS-20 command level. Typing EXIT will also return you to TOPS-20 
command level. 



6.3.2.6 Loading a Line Controller (2020) - The LOAD CONTROLLER 
command loads and starts a communications line controller from a 
specified file. 

The format of the LOAD CONTROLLER command is: 

LOAD CONTROLLER ctlrid (FROM) filespec 

where : 

ctlrid identifies the controller being loaded. The format of 
ctlrid is: 

dev_ctlr 
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where : 

dev is the device type, KDP 

ctlr is the controller number 

filespec is the file specification for the specific program to be 
loaded. The distributed program is COMIOP.KMC. 

Both ctlrid and filespec are required entries. 



6.3.2.7 Dumping a Line Controller (2020) - The DUMP CONTROLLER 
command initiates a memory dump of a communications line controller to 
a specified file. 

The format of the DUMP CONTROLLER command is: 

DUMP CONTROLLER ctlrid (TO) filespec 

where : 

ctlrid identifies the controller being dumped. The format of 
ctlrid is described in Section 6.3.2.6. 

filespec i s the identification of the file receiving the memory dump. 

Both ctlrid and filespec are required entries. 



6.3.2.8 Starting a Line (all models) - The SET STATE LINE ON command 
initializes the DDCMP line protocol on a specified line. The local 
NSP, notified that the line is active, sends a node initialization 
message over the line. 

The format of the SET STATE LINE ON command is: 

SET STATE LINE lineid ON 

where : 

lineid is a required entry and identifies the line being started. 
The format of lineid is described in Section 6.3.1.6. 



6.3.2.9 Starting a Line for Controller Loopback (2020) - The SET 
STATE LINE CONTROLLER-LOOPBACK command initializes the DDCMP line 
protocol and results in a node initialization message being sent as in 
Section 6.3.2.8. In addition, the line controller represented by the 
devctlr portion of lineid is notified to internally reflect any 
messages that are directed to the specified line. 

The format of the SET STATE LINE CONTROLLER-LOOPBACK command is: 

SET STATE LINE lineid CONTROLLER-LOOPBACK 

where : 

lineid is a required entry and identifies the line that is to be 
started in controller loopback mode. The format of lineid 
is described in Section 6.3.1.6. 
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6.3.2.10 Starting a Line for Cable Loopback (2020) - The SET STATE 
LINE CABLE-LOOPBACK command initializes the DDCMP line protocol and 
results in a node initialization message being sent as in Section 
6.3.2.8. When a loopback connector is placed on the line to reflect 
data, the synchronous line unit's internal clock provides the 
necessary synchronization to correctly receive the reflected data, 
replacing the modem clock. 

The format of the SET STATE LINE CABLE-LOOPBACK command is: 

SET STATE LINE lineid CABLE-LOOPBACK 

where : 

lineid is a required entry and identifies the line that is to be 
started in cable loopback mode. The format of lineid is 
described in Section 6.3.1.6. 



| 6.3.2.11 Stopping a Line (all models) - The SET STATE LINE OFF 
command terminates the DDCMP line protocol on a specified line. The 
line is no longer available for transmitting data. 

The format of the SET STATE LINE OFF command is: 

SET STATE LINE lineid OFF 

where : 

lineid is a required entry and identifies the line being 
deactivated. The format of lineid is described in Section 
6.3.1.6. 



6.3.2.12 Performing a Loopback Test (2040,2050,2060) - The LOOP LINE 
command performs a loopback test on a specified line on the current 
EXECUTOR node. The communications front end should be the current 
EXECUTOR. To determine the current EXECUTOR node, use the SHOW 
EXECUTOR command (Section 6.3.3.2). To change the current EXECUTOR 
node, use the SET EXECUTOR command (Section 6.3.3.1). 

The format of the LOOP LINE command is: 

LOOP LINE lineid COUNT count LENGTH length WITH { ZEROES 

{ MIXED 



ONES 



where : 



lineid specifies the line being tested; see Section 6.3.1.6 
for the definition of lineid. 

count Specifies the number of blocks of data to be used in 

the test. This number must be entered in octal. 

length specifies the length of each block of test data. 

ZEROES specifies that the test data will be made up of all 
MIXED zeroes, all ones, or mixed ones and zeroes. One of 

ONES these keywords must be entered. 
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6.3.2.13 Interrogating Node Status (all models) - The SHOW STATUS 
LOCAL commands display the status of the node that is processing the 
command. The node that is processing the command (EXECUTOR node) can 
be determined by using the SHOW EXECUTOR command (Section 6.3.3.1). 
Use the SET EXECUTOR command (Section 6.3.3.1) to change the EXECUTOR 
node . 

The format of the SHOW STATUS LOCAL command is: 

SHOW STATUS LOCAL 

The response includes date, time, node name, node number, the 
operating system, the routing and communications versions of NSP being 
used, the state of the node, and the default host node, if known. 



6.3.2.14 Interrogating Line Status (all models) - The SHOW STATUS LINE 
commands display the status of all or specific lines on the node that 
is processing the commands. The node that is processing the command 
(Executor node) can be determined by using the SHOW EXECUTOR command 
(Section 6.3.3.2). Use the SET EXECUTOR command (Section 6.3.3.1) to 
change the EXEUCTOR node. 

The formats of the SHOW STATUS LINES commands are: 

SHOW STATUS LINE lineid 

and 
SHOW STATUS KNOWN LINES 



where : 
lineid 

KNOWN LINES 



Identifies the specific line for which the status is 
being requested. See Section 6.3.1.6 for the 
definition of lineid. 

requests the status of all lines known to the EXECUTOR 
node. KNOWN LINES is not available for 32K DN20s. 



6.3.3 Miscellaneous Commands 



6.3.3.1 Setting and Displaying Executor Node (all models) - The SET 

EXECUTOR command specifies which node is to process subsequent 
commands. The default executor node at system startup is the physical 
node at which your login occurred. The SHOW EXECUTOR command 
indicates which node is currently processing your commands. 

The format of the SET EXECUTOR command is: 



SET EXECUTOR nodename 
where : 
nodename 



is the name of the node that is to process subsequent 
NETCON commands. 



The format of the SHOW EXECUTOR command is: 



SHOW EXECUTOR 
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The response takes the form: 

Current EXECUTOR is node nodename 



6.3.3.2 Turning Event/Error Logging On or Off (2040,2050,2060) - In 

the DECnet communications front end (the DN20) the line drivers (DTE, 
KDP, DMC) report hardware errors and protocol error thresholds 
(DDCMP) . Event/error logging is supported for DECSYSTEMs-2040/50/60 
with 128K words in the DN20 DECnet-20 communications front end. 

The NICE task in the DN20 acts as a concentrator for messages coming 
from all processes, and forwards these messages to NETCON in the host 
computer. Thus there are two ways to control the flow of 
event-logging messages: the drivers can be notified to send or not 
send messages to the NICE task in the DN20; the NICE task can be 
notified to forward or not forward the messages to NETCON. 

To enable or disable event logging at the line level (messages no 
longer sent to the NICE task in the DN20) , the command format is: 

ENABLE ) (LINE lineid) 

> EVENT-LOGGING < > 

DISABLE ) ( KNOWN LINES ) 

To enable or disable the forwarding of event-logging messages to 
NETCON, the command format is: 

( ENABLE ) 

< > event-logging 
(disable ) 

When a DISABLE EVENT-LOGGING command is given with a line parameter, 
the messages are lost from the time of DISABLE to the time you ENABLE 
EVENT-LOGGING. When a DISABLE EVENT-LOGGING command is given without 
a line parameter, all event/error messages are lost until another 
ENABLE EVENT-LOGGING command is given. 

The command to enable or disable the forwarding of event-logging 
messages to NETCON is independent of the on/off setting of the lines. 



6.3.3.3 Getting Another Copy of the TOPS-20 Command Processor (all 
models) - The PUSH command gives you another copy of the TOPS-20 
command processor. The format is: 

PUSH 



6.3.3.4 Executing NCP Commands From a File (all models) - The TAKE 
command will accept any file specification of a file containing NCP 
commands. The default file type is .CMD. The format is: 

TAKE filespec 
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6.4 RESTART PROCEDURES 

The NETCON process can be restarted with the following command 
sequence: 



@ENABLEQiTj 

$ADVISE OPERATORQED 

TTY213, EXEC 

TTY2, OPR 

TTY211, FAL 

TTY210, NETCON 

TTY207, BATCON 

TTY205, PTYCON 
TTY: 210QID 
[Pseudo-terminal, confirm] ( ret ) 

Escape character is <CTRL>E, type <CTRL>~? for help 
OPERATOR job 3 NETCON 

LINK FROM OPERATOR, tty 3 
[Advising] 

(ctrl/c) 

$RESETQiD 

$RUN SYS: NETCON ( f^Q 

(ctrue) ;(Note: ~E does not echo on terminal) 
[Advice terminated] 
$ DI SABLE GTT) 
a 

When NETCON is restarted all knowledge of the network is lost. 
Therefore you must repeat all commands to identify the various DN20 
(and DN200) data base elements. (See Section 6.3.1.) 

If the ORION process fails while the NETCON process is running, the 
following NETCON warning message is displayed: 

% NETCON: ORION is not running 

Whenever this occurs, ORION must be reloaded using the "ESPEAK 
command . 

The ORION process can be restarted with the following command 
sequence: 

@ ENABLE C- RjiJ ;enable capabilities 

$"ESPEAK C^Q ;give "ESPEAK command 

[PLEASE TYPE SYSJOB COMMANDS - END WITH ~ Z ] ; 
KILL SYS: ORION (*iT) 



RUN SYS: ORION QeD jrestart ORION 

(ctrl/i) ;end the "ESPEAK command 

$DISABLEQlD ;disable capabilities 

@ 

In addition, because the new copy of ORION has no knowledge of 
NETCON's location, NETCON must also be reloaded. The initialization 
routine in NETCON sends a message to ORION identifying itself. 
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6.5 OPERATOR MESSAGES 

When running DECnet-20, there are a number of messages that can appear 
at the operator's console. Some of these abort NETCON and stop 
network processing; others are warnings and allow NETCON to continue. 
Still others merely confirm network commands. DECnet-20-related 
messages can be categorized as follows: 

• Responses (normal or error) resulting from the execution of 
NETCON commands 

• Warning messages due to temporary inhibitions to network 
operations 

• Fatal error messages that reflect program problems severe 
enough to abort the NETCON process 

• Error messages from the NETCON command parser (OPR) due to 
problems in parsing commands or forwarding commands through 
ORION to NETCON 



6.5.1 NETCON Command Responses 

All NCP commands that are processed by the NICE module of the NETCON 
program are assigned a Request Number and placed in the NCP-REQUEST 
queue. The user receives a meaningful response and the Request 
Number. Currently, some commands that are not processed by the NICE 
module respond only with the NCP prompt to indicate the program is 
ready for the next command. Examples of commands with the NCP prompt 
as the only response are SET EXECUTOR, SET LOGGING-INTERVAL, and SET 
LINE. All SHOW commands are followed by a response and time stamp (no 
Request Number). 



6-26 



RUNNING DECnet-20 

Following are examples of each of the three types of responses. 

NCP>set executor 2102 
NCP> 

(NCP prompt only) 

NCP>show executor 

NCP> 

16:33:11 Current EXECUTOR is node 2102 

(Response and time stamp) 

NCP>show sta kn li 

NCP> 

16:33:52 NCP request #23 [SHOW STATUS KNOWN LINES] 

Status as of 18-Oct-79 16:33:51 

Line ID State Adjacent Node 

DTE20_0_0 Off 
DTE2 0_1_0 Off 
DTE20_2_0 Off 
DTE20_3_0 Off 

Function completed successfully 

NCP> 

(Response, Request Number, and time stamp) 

If the NSP link disappears, the message that is output is: I 

NSP link died | 

If a command cannot be successfully completed, one of the 
following messages may be displayed and NCP will prompt for the 
next command. 

Invalid function or option I 

NCU process not available | 

No room for new entry | 

In all of the following situations, NETCON continues to operate. 
If the condition cannot be remedied by retrying, refreshing data 
files, or correcting hardware problems, report it to the Software 
Services representative or submit a Software Performance Report 
(SPR) . 

File I/O error 

This message is due to either a file read error or a disk 
write error. For a read error, try to restore a good copy 
of the file. For a write error, have the hardware problem 
corrected. 
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Line protocol error 

DTE20 (or DN200) hardware problem occurred during a 
down-line load operation or a problem with the bootstrap ROM 
in the communications front end. 

Configuration data base error 

Invalid or missing entries in the network data base. 

Invalid file 

One of the load or bootstrap files cannot be found or is not 
in the correct format. 

Invalid server id 

Invalid node id 

The command specifies a node name that does not follow the 
naming convention for nodes. (See Section 2.1.4.) 

Line communications error 

An error occurred in the DTE20 (or DN200) hardware or a 
system was generated that cannot fit in available memory. 

Line in wrong state 

Invalid line id 

The line identification given as an argument in the NCP 
command is invalid. (See Section 6.3.1.2.) 

Network communications error 

Normally this message means that NETCON cannot communicate 
with the NICE process on a node. The problem could be at 
either end (resource problems, for example). 



6.5.2 NETCON Warning Messages 

NETCON warning messages are displayed whenever unexpected conditions 
arise during the execution of network control functions or network 
utilities. NETCON continues to run and the condition will either 
disappear due to improved system resources or will worsen to the point 
of a fatal error message. Warning messages are preceded by a line 
containing the time of day in the format hh:mm:ss. 



| % NETCON 

| % NETCON 

% NETCON 

% NETCON 

% NETCON 



Could not open any JFNs for the NCU task 

Could not create a PID for receiving ORION messages 

Could not send "HELLO" message to ORION 

Could not set up PID interrupt channel 

No more free pages available 
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% NETCON 
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Attempt to return an illegal page address 

Attempt to return a page that is already on the free list 

No more free space available 

Attempt to return a free block outside the free pool area 

Attempt to return space already marked as in the free pool 

ORION is not running 

Failed to successfully send a message to OPR 

Unimplemented NETCON command 

Unknown internal NETCON message type 

Exhausted table space for the known nodes 

All server JFNs in use 

NCU process halted prematurely 

Unknown message type received from ORION 

JSYS error 

Could not get name of local node 

Could not log line counters for communications line 

Could not initiate Logging Process 

Invalid line-id 

Could not open file 

Bad data in load file 



The foregoing warning messages reflect potential or actual program 
problems; they should be reported via Software Performance Reports 
(SPRs) . 



6.5.3 NETCON Fatal Error Messages 

Whenever NETCON finds itself in a situation where it cannot 
effectively continue operation, a fatal error message is displayed at 
the operator's console. Fatal error conditions should be reported to 
the Software Services representative and documented via a Software 
Performance Report (SPR) . The SPR should include the text of the 
error message as well as information with which the error can be 
reproduced . 

The fatal error messages listed below are the result of some internal 
program error. Since NETCON is no longer running, any attempt at 
recovery must begin with reloading NETCON as described in Section 6.3. 
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? NETCON: Pushdown list overflow at location: nnnnnn 

NETCON tried to add an item to the pushdown list and 
exceeded the specified list size. 

? NETCON: Illegal memory read at location: nnnnnn 

NETCON tried to read data from an area that appears to be 
inaccessible . 

? NETCON: Illegal memory write at location: nnnnnn 

NETCON tried to write data to an area that appears to be 
unavailable for writing. 

? NETCON: Illegal instruction at location: nnnnnn 

NETCON tried to execute what it thought was an instruction 
and found an invalid instruction code. 

? NETCON: Machine size exceeded at location: nnnnnn 

NETCON ran out of some monitor resource while executing a 
JSYS operation. 

? NETCON: I/O data error or parity error at location: nnnnnn 

NETCON encountered an unrecoverable data or parity error 
while reading a file or writing to disk. 

? NETCON: Fatal error at location: nnnnnn 

NETCON encountered an undetermined fatal error at the 
specified location. 

? NETCON: Could not open topology server links. 

This is possibly due to too many open network links. 

Each of the above fatal error messages is followed by some specific 
monitor error message or the following: 

(Unknown monitor error code) 



6.5.4 Other Error Messages 

Before a NETCON command is processed by NETCON, the command is handled 
by both the OPR and ORION programs. Each of these processes checks 
the command for syntax and intent. 



6-30 



RUNNING DECnet-20 

The following error messages are issued by OPR due to errors detected 
by OPR. In each case, the command is ignored and OPR prompts for the 
next entry. Reenter the command correctly. 

PInvalid command "text" 

This message occurs when OPR does not recognize the initial word 
of the command line as a valid command name. "text" is the word 
that OPR tried to parse as a command name. 

PCan't find file "filespec" 

This message occurs when a file, specified in a command line, 
cannot be found. "filespec" is the actual string submitted to 
the GTJFN monitor call. 

PCan't Open TAKE Command File 

This message occurs when the command file specified in a TAKE 
command cannot be opened. (The OPENF monitor call failed.) 

PCommand error: string 

This message occurs when a command line cannot be parsed. String 
is the text resulting from the translation of a JSYS error number 
by the ERSTR monitor call. 

The following messages are issued by OPR due to errors detected by 
ORION. In each case, recovery is possible. 

hh:mm:ss No Processor for Object 

This message occurs if NETCON is not running or if ORION has been 
reloaded without reloading NETCON. Reload NETCON as described in 
Section 6.3 and reenter the command. 

hh:mm:ss Insufficient Privileges Enabled 

This message occurs if OPR is being run without having OPERATOR 
or WHEEL privileges enabled. The message is displayed when OPR 
is first invoked, and again for each command submitted to OPR. 
Obtain OPERATOR or WHEEL privileges, enable them (ENABLE 
CAPABILITIES command) , and rerun OPR. 

The following messages are also issued by OPR due to errors detected 
by ORION; however, the errors are due to communications problems 
between OPR and ORION and should be reported to the software 
specialist. 

hh:mm:ss Message Too Short 

ORION received a message from OPR that was shorter than the 
allowed minimum. 

hh:mm:ss Bad Message Length 

ORION received a message that was shorter than the length 
specified in the message. 

hh:mm:ss Illegal Message Type 

ORION received a message with an illegal message type code. 
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hh:mm:ss Wrong ORION Message Version Number 

ORION received a message specifying a version number different 
from that of the running version. 

hh:mm:ss Unidentified Processor Type 

ORION received a command intended for a processor other than 
NETCON. 

hh:mm:ss Illegally Formatted Command Message 

ORION received a command that it did not understand. 

If the OPR program is started at a time when ORION is not running, the 
initial message that OPR uses to identify itself to ORION cannot be 
sent. Information in the following format is displayed at the 
operator's console; the actual values will, of course, be different. 

?Stop code - SOF - in module OPR on 13-Oct-77 at 15:04:06 
Reason: Send to ORION Failed 

Program is OPR Version 1(12) using GLXLIB Version 1(20) 
Last GLXLIB error: (No errors yet) , 
Last TOPS-20 error: 601130 (Invalid index into system PID table) 

Contents of the ACs (Crash block starts at location 600000) 

0/ 777777777777 400000 612000616 

4/0 

10/ 

14/ 777731001321 

Last 9 Stack Locations: 

-1(P)/ -2(P)/ -3(P)/ 

-4(P)/ -5(P)/ -6(P)/ 

-7(P)/ -8(P)/ -9(P)/ 

HLT: 401202/ HALTF 
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TERMINAL USER'S GUIDE 



CHAPTER 7 
COMMUNICATING WITH THE SYSTEM 



As a nonprivileged terminal user, you communicate with the system by 
using the TOPS-20 Command Language (EXEC) . This chapter assumes that 
you are familiar with the most frequently used TOPS-20 commands (both 
for timesharing and Batch). TOPS-20 commands that relate directly to 
DECnet functions are described in this chapter. 



NOTE 

If you have had little experience with 
the TOPS-20 Command Language, refer to 
the list of suggested documents in the 
Preface of this manual. As an absolute 
minimum, you should read the following 
manuals before continuing with this and 
the following chapter: 

TOPS-20 User's Guide 

TOPS-20 Commands Reference Manual 

TOPS-10 and TOPS-20 Batch Reference 

Manual 



You should know, or have readily at hand, the node name of your 
central processor and the name of all remote nodes with whom you will 
communicate. If remote nodes require a user name, password, or 
account, you will need to know the specific way in which this 
information must be formatted. Your installation should have the 
basic user's manuals for all systems accessible to you via DECnet. If 
you need help, see your system manager or operator. 

The TOPS-20 operating system in conjunction with DECnet software 
allows you to do the following: 



• List accessible DECnet nodes 
DECNET command. 



using the TOPS-20 INFORMATION 



List your logical DECnet node using 
JOB-STATUS command. 



the TOPS-20 INFORMATION 



• Direct output to accessible DECnet nodes using the TOPS-20 SET 
LOCATION command or the TOPS-20 DESTINATION-NODE: node switch 
for queue-class commands. 

To delete files from an accessible DECnet node and to transfer files 
to or from an accessible DECnet node, use the Network File Transfer 
(NFT) program. (The NFT program is described in Chapter 8, Network 
File Transfer.) 
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7.1 INFORMATION COMMAND 

The INFORMATION command has two options that give DECnet information 
INFORMATION DECnet and INFORMATION JOB-STATUS. 



7.1.1 Information DECnet 

INFORMATION DECNET lists the accessible DECnet nodes. 

The format of the INFORMATION DECNET command is as follows 

^INFORMATION (ABOUT) DECNET NODES 
Example : 



@infORMATION (ABOUT) decnetQID 



Accessible DECNET nodes are: 1031, 2102, 4097, DN200, DN20A, 
DN20L, SYS880 



(Note that NODES is assumed as default if omitted. 



7.1.2 Information Job-Status 

INFORMATION JOB-STATUS lists your logical node if your logical node is 
not your physical node. 

The format of the INFORMATION JOB-STATUS command is as follows: 



@ INFORMATION (ABOUT) JOB-STATUS 
Example: 

Gp 

^INFORMATION (ABOUT) JOB-STATUS QlD 
Job 41, User SKOGLUND, MISC : <SKOGLUND> , Account 341, TTY225 
Located at 1031 



7.2 SET LOCATION COMMAND 

The SET LOCATION command instructs the TOPS-20 operating system to 
regard the specified node as your logical node. Your logical node 
determines where your queued output goes. When you log in, your 
logical node is the same as your physical node. Currently, this 
command is effective only when the specified node is controlled by the 
local host. For example, the SET LOCATION command is useful when you 
wish to send several messages or print requests to the remote station 



7-2 



COMMUNICATING WITH THE SYSTEM 

The format of the SET LOCATION command is: 

@SET LOCATION (TO) node:: 

where : 

node:: The name of the node that becomes your logical node. 
If no node name is entered, the node name defaults to 
the name of your physical node. 

Example : 

@set location dn200 : : ( ret ) 

@print test. txt C ret ) 

[Job TEST Queued, Request-ID 550, Limit 27] 

@ 

If you give the INFORMATION JOB-STATUS command immediately following 
the SET LOCATION command, you can check to be sure your logical 
location has changed before you continue: 

$set locATION (TO) dn200: :QED 
@i jQet} 

Job 62, User CIRINO, Account 341, TTY106 
Located at DN200 
(The above example shows how abbreviation may be used.) 

Remember that the request remains on the queue until it is honored. 
If it appears that the request is being ignored, use the INFORMATION 
DECNET command to see if the DN200 is still available. If it is 
available, repeat the INFORMATION DECNET command later; if it is not 
available, check with your operations staff if the job is critical. 
(The DN200 may require manual loading.) 

Printed on the DN200 printer is: 

This is a test file! 

(the contents of the file TEST. TXT) . 

The SET LOCATION command may also be used to direct requests to the 
local site's remote station (DN200) . If the operator is not at the 
terminal of the remote station, the response to your PLEASE request 
will be delayed. The example below shows the input and output at both 
the local site and the remote station: 

Typed on user's terminal at host site: 

@set location dn200: : ( ret ) 

( ESC ) ( ESC ) 

@infORMATION (ABOUT) joB-STATUS CET) 

Job 33, User CIRINO, Account 341, TTY106 
Located at DN200 
@please turn printer on ( *»' ) 

[Operator Notified at 15: 21: 09. . .Please wait for reply] 
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Output to console at remote site: 

2102: :OPR> 

2102: : 

15:21:09 <8> — Message from Timesharing User 
JOB 33 CIRINO at Terminal 106 
PLEASE turn printer on 



Input by remote operator: 

2102: :OPR>RESPOND 8 PRINTER IS ONQID 
2102: :OPR> 



Answer received at host site: 

[Operator Response Received at 15:21:58] 
PRINTER IS ON 



7.3 /DESTINATION-NODE SWITCH 

The /DESTINATION-NODE switch is used with the PRINT command to direct 
output to the specified node. When this switch is used with the 
SUBMIT command, the log file is directed to the specified node. 

The format for the /DESTINATION-NODE switch is as follows: 

/DESTINATION-NODE : node : : 
where : 

node:: The name of the node where output is directed. 
Example: 

@PRINT FOO.BAR/DESTINATION-NODE:ABC: : C^FT ) 

7.4 ADDITIONAL FEATURES AVAILABLE TO NONPRIVILEGED USERS 

The File Transfer Program described in the next chapter can be run by 
a nonpr ivileged user. 

Appendix F describes three programs that use DECnet-20*s task-to-task 
communications capabilities. These programs, NRT20, NRTSRV, and 
STNRT, allow a privileged or nonpr ivileged user at a terminal to log 
in to a remote host on the same network as the user's local host. 
Appendix F describes the function and use of these three programs. 

All users may use the SYSERR program to type or print network error 
and event logging reports. (See Section 10.3.7.) 
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8.1 OVERVIEW 

The Network File Transfer (NFT) program allows you to access or delete 
files residing on DECnet hosts that provide network file access 
capabilities. These capabilities are usually provided by a File 
Access Listener (FAL) program. NFT deletes files from a remote host 
and transfers sequential files between your local host and a remote 
host; FAL checks for requests made by NFT. The NFT and FAL programs 
communicate using the Data Access Protocol (DAP) . 

All network file transfers must be direct requests between the local 

host and one remote host. Files can be transfer red from your local 
host to a remote host or from a remote host to your local host. 

The files deleted or transferred using NFT can be text, program, data, 
control, or any other sequential files. 

DECnet-20 does not support network file spooling. Unless you are 

using the wildcard feature, you can make only one file transfer 

request at a time and that request must be for only one file to be 
transferred. (See Section 8.2.1.) 



8.1.1 Specifying File Access Information 

Each file deletion or transfer request must include a valid user 
identification, account, and password for the system to be accessed. 
The FAL at the remote host is responsible for verifying your access to 
the requested file and the subsequent honoring or rejecting of your 
request. The requirements of the remote node determine the values you 
specify in access information switches or in response to prompts for 
access information. This security measure is necessary to protect a 
node's files from unauthorized access or accidental deletion. You 
must enter either the particular access parameter required by the 
remote node, or a carriage return if the remote node does not require 
a parameter or has an established default value. 

NFT prompts you for access information (user, account, password) when 
you type the first NFT command that requires such information. If the 
access is successful, all subsequent file requests to the node 
addressed will use the access information that you provided in 
response to the prompt. If you type the SET DEFAULTS command as the 
first NFT command, or if you have set defaults for the node in an 
NFT.INIT file in your logged-in directory, you will not be prompted 
for access information. Whether you supply access information in 
response to a prompt from NFT, by the SET DEFAULTS command typed to 
your terminal, or by SET DEFAULTS commands in an NFT.INIT file, the 
values will be remembered. (The NFT.INIT file is read each time you 
run NFT.) 
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Access information entered in response to a prompt or with a SET 
DEFAULTS command remains effective until changed with another SET 
DEFAULTS command. Access information switches are used to override 
default values already established. Switch values are effective only 
for the command in which entered. 



8.2 NFT COMMANDS 

You call the NFT program by typing NFT or R NFT in response to the 
TOPS-20 operating system prompt. After you type NFT and press RETURN, 
the NFT program prints the prompt NFT>. If you want to see the list 
of valid NFT commands, type the question mark character (?) . 

Example: 

qNFT C *et ) 

NFT>? one of the following: 
COPY DELETE DIRECTORY EXIT HELP 

INFORMATION SET SUBMIT TAKE TYPE 

NFT> 



NFT also offers the recognition feature of TOPS-20. If you type an 
NFT command after the NFT prompt and then press the ESCape key, NFT 
displays one or more guidewords to prompt you for the next response. 
Guidewords are enclosed in parentheses. After a guideword, type the 
question mark character (?) to display the list of valid responses. 
Additional guidewords and valid responses can be shown by repeating 
the alternate use of the ESCape key and the question mark character 
until all the input requirements for that command are satisfied. 

The file specifications for remote files must have the format required 
by the operating system at the remote host. The operating systems and 
corresponding formats include the following: 



Operating system 

TOPS-20 
VAX/VMS 
RSX, RSTS and IAS 



File Specifications Format 

device : <directory>f ilnam.ext.gen 
device: [username] f ilnam.ext ;gen 
device: [UIC] f ilnam.ext ;gen 



8.2.1 SET DEFAULTS Command 

The SET DEFAULTS command establishes the default access information to 
be used with all subsequent NFT commands for the specified node. The 
values established with the SET DEFAULTS command remain in effect 
until you exit from NFT or change the values with another SET DEFAULTS 
command. The SET DEFAULTS command does not prompt for omitted 
information. However, NFT does prompt for required omitted access 
information switches at the time you type the first command that 
requires a switch not previously set with a SET DEFAULTS command. 

Access information values may be changed for a specific command by 
including the desired access information switch. After the command 
containing the switch has been executed, the access information values 
revert to the previously established default values. 
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The format of the SET DEFAULTS command is as follows: 

NFT>SET DEFAULTS (FOR NODE) node :: /switches 

where : 

node:: is the node name to which the default values are 
assigned . 

/switches are any combination of access information switches 
(see Table 8-1) and, in addition, the switch 
/OSTYPE:operating system. Valid values for the 
operating-system argument are TOPS20, RSX11, RSTS , 



VMS, or IAS. 



Examples: 

@NFTQTT) 



NFT>SET DEFAULTS (FOR NODE) ALPHA :: /USER: JONES/OSTYPE : VMS(_?i 



1 , v 

NFT>SET DEFAULTS T (FOR NODE) DELTA :: /USER: CLEMENS/PASSWORD : TOPS20 CUD 



NFT>SET DEFAULTS (FOR NODE) GAMMA : : /USER : REILLY/ACC : UETP (""""") 
NFT> 

You can place SET DEFAULTS commands in an initialization file that 
will be read when you run NFT. The initialization file must be in 
your logged-in directory and must be called NFT.INIT. Values set in 
an NFT.INIT file are effective until they are changed in the NFT.INIT 
file. Access information established in the NFT.INIT file may be 
changed by typing a SET DEFAULTS command, or may be overridden by an 
access information switch. The SET DEFAULTS command you type at the 
terminal will be effective for the current NFT run unless you change 
or override it. The access information switch is effective only for 
the command in which it is specified. 

Following is an example of an NFT.INIT file currently in use. The 
INFORMATION DECNET command included at the end provides a convenient 
way to check the currently available nodes whenever you run NFT. 

@type ps: <PTAYLOR>nf t . init C^O 

SET DEFAULTS 2102 : .-/USER: PTAYLOR/ACCOUNT: 341/OSTYPE : TOPS20 

SET DEFAULTS 1031 :: /USER: PTAYLOR/ACCOUNT: 341/OSTYPE : TOPS20 

SET DEFAULTS SYS880: :/USER:GUEST/ACCOUNT: FOO/OSTYPE : RSXll/PASS : DUMB 

SET DEFAULTS 4097: :/USER: REILLY. PTAYLOR/ACCOUNT: 341/OSTYPE : TOPS20 

SET DEFAULTS 2137 : :/USER: REILLY/ACC : UETP 

INFORMATION DECNET 

You may clear the default access information for a node by typing the 
SET DEFAULTS command without specifying any access information. To 
clear the default access information for a node other than the node 
where your logged-in directory is located, the node name must be 
included. If you omit node name, the system assumes the node to be 
the node where your logged-in directory is located. 
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Two examples are shown below. In Example 1 there is no NFT.INIT file 
in the logged-in directory. In Example 2 there is an NFT.INIT file 
with default access information for four nodes as shown. The NFT.INIT 
file also includes the INFORMATION DECNET command. Including this 
command in the NFT.INIT file saves you from having to type the command 
at the beginning of each NFT run. Note in the first example that the 
default access information is available for the node where your 
logged-in directory is located even though you have not given a SET 
DEFAULTS command. NFT establishes these parameters each time the NFT 
or R NFT command is given. 

When you exit from NFT, all default access information as cleared or 
set in the NFT run from which you have exited is lost. If you run NFT 
again and type the INFORMATION DEFAULTS command before any SET 
DEFAULTS commands are given the response will always be either the 
default access information for the node where your logged-in directory 
is located (no NFT.INIT file) or defaults given by the SET DEFAULTS 
commands in the NFT.INIT file. 

Example 1. 

@NFT ( ret ) 

( Fsr) ( fs ( ^ 

NFT>inFORMATION (ABOUT) deFAULTSGID 

Node 2102: :/USER:CIRINO/ACCOUNT: 341/OSTYPE:TOPS20 

NFT>set deFAULTS (FOR NODE )C^T> 

( ES( ) C E«' ) 

NFT>inFORMATION (ABOUT) deFAULTSCji 
Node 2102: :/OSTYPE:TOPS20 

NFT> 
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Example 2. 



@nftQID 

Accessible DECNET nodes are: 2102, 1031, 4097, DN200, DN20A, 
DN20L 

dsD ( esc ) 

J I 

NFT>inFORMATION (ABOUT) deFAULTS fi^FT ) 

Node 2102: :/USER:PTAYLOR/ACCOUNT: 341/OSTYPE:TOPS20 

Node 1031: : /USER: P: TAYLOR/ACCOUNT: 341/OSTYPE :TOPS20 

Node 4097: : /USER: REILLY.PTAYLOR/ACCOUNT: 341/OSTYPE :TOPS20 

Node SYS880: :/USER:GUEST/ACCOUNT: FOO/OSTYPE : RSXll 



NFT>set deFAULTS (FOR NODE)QI7 



NFT>inFORMATION (ABOUT) deFAULTSQED 

Node 2102: :/OSTYPE : TOPS20 

Node 1031 : :/USER: PTAYLOR/ACCOUNT : 341/OSTYPE : TOPS20 

Node 4097:/USER:REILLY. PTAYLOR/ACCOUNT: 341/OSTYPE : TOPS20 

Node SYS880: :/USER:GUEST/ACCOUNT: FOO/OSTYPE: RSXll 



NFT>set deFAULTS (FOR NODE) 10 31: z Q^T) 

( ESC ) ( tSC ) 

NFT>inFORMATION (ABOUT) de FAULTSQlD 

Node 2102: :/OSTYPE:TOPS20 

Node 1031: :/OSTYPE:TOPS20 

Node 4097: :/USER:REILLY. PTAYLOR/ACCOUNT: 341/OSTYPE: TOPS20 

Node SYS880: : /USER: GUEST/ACCOUNT: FOO/OSTYPE: RSXll 

NFT> 



8.2.2 INFORMATION Command 

The INFORMATION command has two options: DEFAULTS and DECNET. 

The INFORMATION DEFAULTS command displays the current settings of the 
default switches for a specified node. 

The format of the INFORMATION command is as follows: 

NFT> INFORMATION (ABOUT) DEFAULTS 
NFT displays the information about defaults in the following format: 

node : :/USER:user id/ACCOUNT:account-str ing/OSTYPE:ostype 

where : 

node:: is the name of the node for which the defaults 

listed have been set. 
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userid is the valid user identification at the 

specified node. 

account-string is the valid account at the specified node. 

ostype is the operating system at the specified node. 

Example : 

@NFTQlD 



NFT> INFORMATION (ABOUT) DEFAULTSQiD 

Node 210A: :/USER:SKOGLUND/ACCOUNT: 341/OSTYPE :TOPS20 
NFT> 

The INFORMATION DECNET command displays the list of accessible DECnet 
nodes. 

The format of the INFORMATION DECNET command is as follows: 

NFT> INFORMATION (ABOUT) DECNET 

Example: 

QNFT ( R^ ) 

QsT) 

NFT> INFORMATION (ABOUT) DECNET (TTT) 

Accessible DECNET nodes are: 1031, 2102, DN20A, DN20L 
NFT> 



8.2.3 COPY Command 

The COPY command transfers files from the local node to a remote node 
or transfers files from a remote node to the local node. 

The format of the COPY command is as follows: 

NFT>COPY (FROM) nodel : : f ilespecl/switches (TO) node2: : f ilespec2/switches 

where : 

nodel:: is the node name of the source host from which the 
file is transferred. The default node is the local 
node. 

filespecl is the file specification of the file to be 
transferred. The specification must be in the 
format required by the operating system at nodel::. 

node2:: is the node name of the destination host to which 
the file is transferred. The default node is the 
local node. 

filespec2 is the file specification to be given to the 
transferred file. The specification must be in the 
format required by the operating system at node:: 2. 

/switches are one or more of the switches defined in Table 
8-1, as required. 
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Table 8-1 
COPY Command Switches 



Access Information Switches (Valid also with SET DEFAULTS, 
DIRECTORY, DELETE, SUBMIT, and TYPE commands) 

/USER.-userid 

Sets the user identification associated with the node 
specified. Userid must be an ASCII string of 1 to 16 
characters. 

/ACCOUNT: account 

Sets the account associated with the user identification at 
the node specified. Account must be an ASCII string of 1 to 
16 characters. 

/PASSWORD : password 

Sets the password associated with the user identification at 
the node specified. Password must be an ASCII string of 1 
to 8 characters. 

Processing Mode Switches 

/ASCII 

Sets the file processing mode to ASCII. 

/IMAGE 

Sets the file processing mode to IMAGE. IMAGE indicates 
that the file is sent or received exactly as stored on disk. 

/MACY11 

Sets the file processing mode to MACY11. This switch is 
required to transfer PDP-11 object code. The MACYll file 
format is produced by a TOPS-10/2Q PDP-11 cross-assembler. 

Record Length Switches (used only in combination with one of the 
processing mode switches) 

/FIXED:nn 

Defines a file as consisting of fixed length records of nn 
bytes. 

/VARIABLE :nn 

Defines a file as consisting of variable length records of 
maximum size of nn bytes. 
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Examples : 

When a sequential file transfer is between two DECSYSTEM-20s , you may 
allow all fields except the filespec fields to be defaulted by 
omitting the switches and the node specification that represents the 
local node. 

Each COPY command in the first three examples is valid for a TOPS-20 
to TOPS-20 transfer. LOCAL is the name of the local node; REMOTE is 
the name of the remote node. 

Example 1. 

@NFTQeT) 

NFT>COPY (FROM) LOCAL::*. MAC (TO) REMOTE ::*. MACQID 

LOCAL: :PS:<USER>ABC.MAC=>REMOTE: : PS : <USER>ABC .MAC [OK] 
LOCAL: :PS<USER>XYZ.MAC=>REMOTE: : PS : <USER>XYZ . MAC [OK] 

The system responds, in this case, by naming all transferred files 
ending in .MAC. This use of the wildcard function is permitted only 
if both nodes support wildcarding. 

Example 2. 



@NFTQe7 



NFT>COPY (FROM) ZOOM.* (TO) REMOTE :: ZOOM. *QiD 

LOCAL: :PS:<USER>ZOOM.EXE=>REMOTE: : PS : <USER>ZOOM. EXE [OK] 
LOCAL: :PS:<USER>ZOOM.MAC=>REMOTE: : PS : <USER>ZOOM. EXE [OK] 

In the above example, the system interprets the wildcard designation 
for file type, transfers the two extant files beginning with the file 
name ZOOM, and defaults the unspecified FROM node name to the local 
node name. Note also the complete file specification inserted by the 
system in both examples. You did not need to type the structure (PS:) 
or user <USER>. 

Example 3. 

(aNFTQIT) 



NFT>COPY '(FROM) REMOTE :: ABC . TXT (TO) ABC.TXT P^T) 

REMOTE: : PS<USER>ABC . TXT=>LOCAL: : PS : <USER>ABC . TXT [OK] 

In this example, the file is being transferred from the remote to the 
local node, whereas in the first two examples the files were being 
transferred from the local to the remote site. 



Example 4. 
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@NFTQe7) 

NFT>COPY TPARS. MAC/ASCI I SY5101: : DBO : TPARS . MAC/ASCII/VARIABLE : 132QI: 

TPARS.MAC => SY5101: : DBO : TPARS .MAC [OK] 

NFT>DIRECTORY SY5101 : : DBO : * . MACQiD 

SY5101: :DB0: [200,200] 
TPARS. MAC;1;P775600 6 11264(8) 15-Aug-79 17:02:07 

The above example differs from the first three examples in two ways. 
First, a file is being copied from the local system to a non-TOPS-20 
system. (SY5101 is an RSX operating system.) Second, guidewords are 
not used. Note that this example includes the /ASCII switch for the 
TOPS-20 source node, and includes the /ASCII/VARIABLE: 132 switches for 
the RSX destination node. 

Specifying File Processing Mode 

When transferring files between TOPS-20 systems, you do not need to 
specify the file processing mode because TOPS-20 has established 
defaults based on file bytesize. The defaults are: 

File byte size Default processing mode 

7 /ASCII 

all except 7 /IMAGE 

Specifying Source File Processing Mode 

When transferring local files to a non-TOPS-20 system, you must 
specify the local (source) file processing mode unless the file is 
bytesize 7. 

When transferring files from the RSTS , IAS, or RT11 operating systems 
to your local system, you must specify the remote (source) file 
processing mode. 

NOTE 

Failure to match remote (source) file 
processing switches with the actual data 
mode of the remote file to be 
transferred will have unpredictable 
results. 
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Specifying Destination File Processing Mode 

For each source file processing mode specified, there is a default 
destination file processing mode. This default value will be assumed 
if no destination file processing mode switch is specified. The 
defaults are: 



Source mode 




Default destination mode/record 


/ASCII 


(TO) 


/ASCII or /ASCII/VARIABLE 


/ASCII/FIXED 


(TO) 


/ASCII 


/ASCII/VARIABLE 


(TO) 


/ASCII 


VMS print file 






format 


(TO) 


/ASCII 


/IMAGE 


(TO) 


/IMAGE 


/IMAGE/FIXED 


(TO) 


/IMAGE/FIXED 


/IMAGE/VARIABLE 


(TO) 


/IMAGE/VARIABLE 


/MACY11 


(TO) 


/IMAGE/VARIABLE 


/MACY11/FIXED 


(TO) 


/IMAGE/FIXED 


/MACY11/VARIABLE 


(TO) 


/IMAGE/VARIABLE 



TOPS-20 NFT permits only the following source/destination file 
processing mode combinations when transferring a file TO a remote 
system: 



Local mode 




Remote mode 


/ASCII 


(TO) 


/ASCII 


/ASCII 


(TO) 


/ASCII/VARIABLE 


/IMAGE 


(TO) 


/IMAGE 


/IMAGE/FIXED 


(TO) 


/IMAGE/FIXED 


/IMAGE/VARIABLE 


(TO) 


/IMAGE/VARIABLE 


/MACY11 


(TO) 


/IMAGE/VARIABLE 


/MAC Yl 1/VARI ABLE 


(TO) 


/IMAGE/VARIABLE 


/MACY11/FIXED 


(TO) 


/IMAGE/FIXED 


/MACY11/IMAGE 


(TO) 


/IMAGE 



TOPS-20 NFT permits only the following source/destination file 
processing mode combinations when transferring a file FROM a remote 
system: 



Remote mode 




Local mode 


/ASCII 


(TO) 


/ASCII 


/ASCII/FIXED 


(TO) 


/ASCII 


/ASCII/ VARIABLE 


(TO) 


/ASCII 


/IMAGE 


(TO) 


/IMAGE 


/IMAGE 


(TO) 


/MACYll/ IMAGE 


/IMAGE/FIXED 


(TO) 


/IMAGE/FIXED 


/IMAGE/FIXED 


(TO) 


/MACY11/FIXED 


/IMAGE/VARIABLE 


(TO) 


/IMAGE/VARIABLE 


/IMAGE/VARIABLE 


(TO) 


/MAC Yl 1/VARIABLE 


/IMAGE/VARIABLE 


(TO) 


/MACYll 
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8.2.4 DELETE Command 

The DELETE command deletes files from a remote node. 
The format of the DELETE command is as follows: 

NFT>DELETE (REMOTE FILES) node : : f ilespec/switches 
Example : 



@nftQiD 
Accessible DECNET nodes are: 2102, 1031, 4097, DN200, DN20A 

NFT>delete 2102: :sep.txtC^) 

Access information for node 2102: :/USER:cir ino/ACCOUNT: 341 

Password : 

2102: :PS:<CIRINO>SEP.TXT.5 [OK] 

NFT> 

If no access information values have been established before the 
DELETE command, NFT will prompt for the required access information 
unless you supply switches with the DELETE command. These switches 
are effective only for the command in which you specify them. 



8.2.5 DIRECTORY Command 

The DIRECTORY command returns a directory listing of the files at the 
specified remote node. The system prints the directory heading and 
then lists the files in alphabetic order. For each file the following 
information is listed: 

• Name, type, generation number 

• Protection code 

• Size in pages 

• Length in bytes and byte size (in parentheses) 

• The date and time the file was originally created or, if 
modified, the date last modified 

The directory heading (node, structure, directory name) and the file 
name, type, and generation number are always in the format required by 
the remote site. All other information is listed in TOPS-20 format. 

The format of the DIRECTORY command is as follows: 

NFT>DIRECTORY (OF REMOTE FILES) node :: f ilespec/switches 

If no access information values have been established before the 
DIRECTORY command, NFT will prompt for the required access information 
unless you supply switches with the DIRECTORY command. These switches 
are effective only for the command in which you specify them. 
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Several examples follow. Both the environment and the timing of the 
DIRECTORY command influence the input/output associated with the 
command. Therefore, each example is preceded by the conditions that 
would call for the input as shown and result in the output as shown. 

Example 1. 

Conditions: The NFT DIRECTORY command is for one file on your 
own logged-in directory. There is no NFT.INIT file. The 
DIRECTORY command is the first command given in this NFT run. 
NFT knows USER and ACCOUNT because you logged in on this node. 
NFT always prompts for password unless it has been established 
with a SET DEFAULTS command. NFT does not print passwords. 



NFT (ret 



» 

NFT>dirECTORY (OF REMOTE FILES) login. cmdGID 

Access information for node 2102: :/USER:KAMANITZ/ACCOUNT: 341 

Password : 

2102: :PS:<KAMANITZ> 
LOGIN.CMD. 7;P777700 1 39(36) 14-Sep-79 14:34:01 



NFT> 
Example 2. 



Conditions: Same as Example 1 except that an NFT TYPE command is 
given before the DIRECTORY command. There is no prompt for the 
password after the DIRECTORY command is given. The TYPE command 
was the first command and the password was entered in response to 
the prompt following the TYPE command. NFT remembers the 
password . 

NFT>type switch. ini(_R£i_) 

Access information for node 2102: :/USER:KAMANITZ/ACCOUNT: 341 

Password : 

EDIT/SAVE : 5/ISAVE : 5 

NFT>dirECTORY (OF REMOTE FILES) login.cmd (HD 

2102: :PS:<KAMANITZ> 
LOGIN.CMD. 7;P777700 1 39(36) 14-Sep-79 14:34:01 
NFT> 
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Example 3. 



Conditions: The DIRECTORY command is for the complete directory 
on another TOPS-20 node that is a member of your network. You 
have an account for node 4097. There is no NFT.INIT file. The 
DIRECTORY command is the first command given that requires access 
to node 4097. A prompt is given for each access information 
parameter . 

@nftQiD ~~T~ 

NFT>DIRECTORY (OF REMOTE FILES) 4097: : C^Q 
Access informa tion for node 4097:: 
User: CRUGNO LAQp D 
Account: 341QID 
Password : 

4097 : : PS : <CRUGNOLA> 

CALEND.EXE. 1;P777700 5 2560(36) 10-Apr-78 11:23:48 

DIDDLE. ZZZ.1;P777700 1 6(36) 6-Aug-79 15:51:41 

LA36.CMD. 1;P777700 1 74(7) 13-Mar-78 16:39:48 

LOGIN.CMD. 2;P777700 1 21(7) 13-Mar-78 16:36:23 

MAIL. TXT. 1;P770400 1 175(7) 26-Jul-79 13:01:46 

PTYCON.ATO.l;P777700 1 1220(7) 19-May-78 13:34:26 

SWITCH. INI. 2;P777700 1 39(7) 18-May-78 15:33:10 

VT50.CMD. 1;P777700 1 28(7) 13-Mar-78 16:37:44 

VT52.CMD. 1:P777700 1 60(7) 13-Mar-78 16:38:49 

ZIP.Q.1;P777700 1 45(7) 14-Jun-78 17:06:25 
NFT> 



Example 4. 



Conditions: Same as Example 3 except that the DIRECTORY command 
uses the wildcard feature to request all files of type .CMD. 

Gp 
@nftQeD \^ 
nft>directory (of remote files) 4097 ::*. cmd qid 

Access informa tion for node 4097:: 
User: CRUGNOLAGJD 
Account: 341 ( ^ ) 
Password : 

4097: :PS:<CRUGNOLA> 

LA36.CMD. 1;P777700 1 74(7) 13-MAR-78 16:39:48 

LOGIN.CMD. 2;P777700 1 21(7) 13-MAR-78 16:36:23 

VT50.CMD. 1;P777700 1 28(7) 13-MAR-78 16:37:44 

VT52.CMD. 1;P777700 1 60(7) 13-MAR-78 16:38:49 
NFT> 
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Example 5. 



Conditions: Two NFT Directory commands are directed to an RSX11 
node that is a member of your network. You have an account on 
SY5101. Your logged-in directory has an NFT.INIT file with a SET 
DEFAULTS command that establishes values for USER, ACCOUNT, 
PASSWORD, and OSTYPE for 5101. The INFORMATION DECNET command is 
also included in the NFT.INIT file. The DIRECTORY command is the 
first command given that requires access to SY5101. The 
directory heading and file specifications are in RSX11 format. 
All other output is in TOPS-20 format. All values apply to the 
remote directory. The first DIRECTORY command is for all files 
on structure DKO. The second command is for all files of type 
.CMD on structure DBO. The wildcard feature is allowed because 
it is implemented by RSXll. 

0NFT ( "i ) 
Accessible DECNET nodes are: 1031, 2102, 4114, DN20H, SY5101 



Gp 



NFT>DIRECTORY (OF REMOTE FILES) SY5101::QjD 

SY5101: :DK0: [200,200] 
INSTALL. CMD;17;P775600 1 1536(8) 27-Dec-78 17:44:26 



Gp 



NFT>DIRECTORY (OF REMOTE FILES) SY5101: : DBO : * . CMP C^T) 

SY5101: :DB0: [200,200] 

MERGE. CMD;1;P565600 1 512(8) 12-May-78 15:45:35 

FLOPPY. CMD;1;P565600 1 512(8) 12-May-78 15:45:36 

PLO.CMD;1;P565600 1 512(8) 12-May-78 15:45:36 

PLOT.CMD;1;P565600 1 1024(8) 12-May-78 15:45:37 

COPIES. CMD;3;P775600 1 512(8) 7-Sep-79 16:45:14 
NFT> 



8.2.6 EXIT Command 

The EXIT command ends NFT execution. See the example in the HELP 
command which follows. 



8.2.7 HELP Command 

The HELP command displays the HELP file for NFT. The HELP file 
contains a description of all NFT commands and switches. The example 
that follows illustrates both the EXIT and HELP commands. CTRL/O was 
typed after the first two sentences of the HELP file. The file is 
approximately 4 pages and you can read it at your convenience. 



Example : 



$R NFTQ1D 

NFT>HELP (~^D 

NFT - Network file transfer program 23-Apr-79 
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NFT is the user interface to the network file transfer system. 
The services NFT provides are actually performed by a FAL (File 
Access Listener) process at the accessed node. 

"0. .. 

NFT>EXITQeD 
$ 



8.2.8 SUBMIT Command 

The SUBMIT command allows a Batch control file to be submitted to the 
Batch input queue at a specified remote node. The network file 
transfer system does not check to determine that the request is 
honored. This command is valid only for nodes that support remote 
command file submission. 

The format of the SUBMIT command is as follows: 

NFT>SUBMIT (REMOTE FILES) node : : f ilespec/switches 

where: 

node:: is the node name of the remote host where the file 
is submitted. 

filespec is the file specification of the remote file. 

/switches are the access information switches. 



8.2.9 TAKE Command 

The TAKE command allows commands to be executed from a command file. 

The format of the TAKE command is as follows: 

NFT>TAKE (COMMANDS FROM) filespecl (LOGGING OUTPUT ON) filespec 2 

where : 

filespecl is the file specification of the local command file. 

filespec2 is the file specification of the local file for 
logging output. 

When commands are executed that cause a prompt for access information, 
the command file execution is momentarily suspended, and you are given 
the prompt for the access information at your terminal. After you 
enter the required access information, the command file execution is 
resumed. This feature allows you to omit passwords from your command 
files. 

8.2.10 TYPE Command 

The TYPE command displays the file specified on your terminal. The 
file is transferred in ASCII. 

The format of the TYPE command is: 

NFT>TYPE (REMOTE FILES) node :: f ilespec/switches 
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8.3 NFT ERROR MESSAGES 

In the course of running NFT, you will probably receive error 
messages. NFT error messages preceded by % are warning messages. 
Warning messages may indicate errors or may give you information. You 
respond to them by taking the indicated action or adjusting your 
procedures on the basis of the information given. Error messages 
preceded by ? are fatal error messages. Except where otherwise 
stated, fatal errors can be handled by you alone, or by you with the 
help of a more experienced user. 

In most messages, both the cause of the error and the action required 
are apparent from the text of the message. Where this is not the 
case, interpretive text is supplied following the message. 



3.1 NFT Warning Message 

%File attributes do not match processing mode 

The file attributes at the remote site do not match those 
specified in the COPY command. This message will be 
received only if you are reading a file at a remote node 
running an operating system other than TOPS-20. 



3.2 NFT Fatal Error Messages 

PCannot close logical link ... - TOPS-20 text for JSYS error 

PCannot do requested file format conversion 

Check the allowable source/destination file processing mode 
combinations (Section 8.2.3). 

PCannot establish requested mode for input 

?Cannot establish requested mode for output 

?Cannot get JFN for logical link ... - TOPS-20 text for JSYS 
error 

PCannot open command file 

Examine the file specification of your .CMD file for errors. 
PCannot open logging file 

Examine the file specification of your .LOG file for errors. 
PCannot open logical link ... - TOPS-20 text for JSYS error 
?Destination file must be specified 
PInvalid account string 
PInvalid destination processing mode 
?Invalid password 
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PInvalid record length 

PInvalid SET command 

PInvalid switches for local file 

PInvalid switches for remote file 

PInvalid switch terminator 

PInvalid use of wild cards 

PInvalid user-id 

PLogical link reception error 

Check to see if your directory on the target system is over 
quota. 

PLogical link transmission error 

PLogical link was aborted ... - disconnect reason text 

PLogical link was terminated 

PRemote file attributes not supported 

PRemote node is not responding 

PRemote node refused connection ... - disconnect reason text 

PRemote status ... - error text 

If your network includes nodes running other than the 
TOPS-20 Operating System, you may receive this message. The 
error text that follows Remote status will be from the 
non-TOPS-20 operating system. Approximately 200 such 
messages are possible. Your local NFT repeats this 
"foreign" message verbatim. You will need help from your 
Software Support Specialist. Because the error message 
originates in the operating system at the remote site, the 
problem cannot be readily resolved. 

PRemote system does not support default mode 

PRemote system does not support file submission 

The NFT SUBMIT command is not implemented at the remote 
node . 

PRemote system does not support requested mode 

PRemote to Remote transfers not supported 

This message is displayed if you use the COPY command to 
transfer a file from one remote node to another remote node. 

PSource file must be specified 

PTOPS-20 text for JSYS error 

This message consists of any appropriate JSYS error message 
not specifically covered in other messages in this list. 
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8.3.2.1 Internal NFT Program Errors - These fatal errors should not 
occur. If any one of these errors does occur, you will need the help 
of your Software Support Specialist. These errors are internal to the 
NFT program. 

?Dap message buffer is full 

PInvalid link index 

PLogical link not established 

PInvalid argument length 

PFunction not implemented 
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GENERATING DECnet-20 



CHAPTER 9 
USING THE CONFIGURATION TOOLS 



If you are running DECnet-20 on a DECSYSTEM-2020 , your only concern 
with this chapter is Section 9.4. This is the section that describes 
how you create the needed directories and restore the task-to-task 
files from the distribution tape. You should ignore all references to 
DN20 and DN200. The steps you execute in Section 9.4 are Steps 4, 5, 
and 6. Go now to Section 9.4. 

Because of the several options now available in both hardware and 
software, each DECnet node on a DECSYSTEM-2040 , 2050, or 2060 has a 
set of tools for customizing the DECnet configuration. There are no 
model dependencies. 

Approximately three hundred files spread over two distribution tapes 
are used to tailor the software for various DECnet-20 configurations. 
The major file types and files are outlined in Section 9.3. 

The tools for configuring the DECnet-20 front-end node (DN20 or DN21) 
for single or multi-line task-to-task are on the DECnet-20 
Task-to-Task Distribution Tape. A successfully installed TOPS-20 
Operating System running a Version 4 monitor is a prerequisite to 
on-site configuration for task-to-task capability. Configuring for 
task-to-task must precede configuring for RJE. The system may be in 
timesharing or standalone mode. 

You will create two directories and one subdirectory on PS: to store 
temporarily the files needed for configuration. You must use the 
parameters given in the step-by-step procedures. You will need at 
least 3900 pages for working storage and 3900 pages for permanent 
storage. Ensure that space is adequate before you begin the 
procedures. 



9.1 CONFIGURATION OVERVIEW 

The logical steps in configuring the DECnet-20 communications front 
end or remote station are summarized below. A detailed step-by-step 
procedure is outlined in Section 9.4. The purpose of the general 
description below is to acquaint you with the configuration 
environment and thus provide a reference point for the information 
that precedes the step-by-step procedure. 
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• Log in and enable with OPERATOR or WHEEL privileges. 

• Create one directory and one subdirectory for DECnet 
generation files: 

PS:<DNGEN> 

PS:<DNGEN.CMDS> 

The various files to be copied into these directories are on 
the distribution tape with the identical structure and 
directory names. 

• Create one directory for documentation and source files: 

PS:<DECNET> 

• Create one directory for example command and output files for 
acceptance testing. 

• Mount the appropriate distribution tape (Task-to-Task or RJE) 
and use the DUMPER utility program to copy the directory 
contents from the tape to the two created directories on disk. 

• Create a directory for your own customized files: 

PS:<DN20-1> 

or 
PS:<DN200> 

• Prepare to build the customized directory. Preparation 
involves logical definitions, CONNECT and ACCESS commands, and 
a TAKE of the appropriate .CMD file. There are three .CMD 
files : 

DN20BLD.CMD 

Sets up the area for multiline task-to-task. 
DN200BLD.CMD 

Sets up the area for the RJE (DN200) option. 

32KBLD.CMD 

Sets up the area for a single line task-to-task DN20 
(32K front end) . 

• Run NETGEN to define the configuration. This is the core of 
the configuration procedure and the step that demands 
preparation on your part. 

• Submit the .CTL file now in your customized directory to the 
Batch system. Output will be files for the system (DN20 or 
DN200) generation and a .LOG file. 

• Inspect the .LOG file output by the batch job to check for 
possible errors in the build process. 

• Continue or rerun NETGEN as indicated by the inspection of the 
.LOG file. (Use the NETGEN command RESTORE.) 
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• Run VNP20. This program creates the system (DN20 or DN200) 
image. 

• The system image created by the VNP20 program now exists as 
PS:<DN20-1> nodename.SYS (or PS:<DN200> nodename.SYS if you 
were configuring for RJE) . If a change in the structure name 
or directory name or both is desired for your site, use the 
COPY command to accomplish the change at this time. 

The file named nodename.SYS is the LOAD-FILE for the named network 
node. This file will be set up for loading into the front end as part 
of the installation procedure. 

At the end of your first NETGEN run for the DN20, if no errors occur, 
your system will include basic task-to-task capability. A second run 
is necessary to generate RJE. In addition, you must repeat the 
configuration procedures whenever you change the network configuration 
(add a line, add a node, or add an option, for example). 

Network File Transfer (NFT) is a utility program that is part of the 

basic DECnet task-to-task package. No customizing is required for 
NFT. 



9.2 PREPARING TO USE THE CONFIGURATION TOOLS 

Your configuration (and installation) procedures will run smoothly if 
you are well-prepared. It is strongly suggested that you observe the 
guidelines below before you begin to use the configuration tools. 

• Read this entire chapter. Configuring the DECnet-20 
communication front end requires an understanding of 
parameters not normally of concern to you. Also, terms used 
in NETGEN have a specific meaning to the program. All 
parameters referenced in the configuration process will be 
explained before a step-by-step procedure for configuring the 
front-end. 

• Hardware parameters specifically entered or accepted as 
defaults MUST reflect the actual hardware in place at your 
site. Software parameters MUST be within the given range. 
Accepting defaults for software parameters is a safe 
procedure, but may not give optimum performance if you have a 
high load average and the maximum number of lines. Do NOT 
enter a value other than the default without understanding the 
tradeoffs described in the documentation. (As previously 
noted, all 32K systems must be configured exactly as described 
in the BEWARE file.) 

• If you have any doubt about the value to type for a parameter, 
check with your system manager. 

• You may find it helpful to make a written list of names, 
symbols, numbers and text strings you will need for use at the 
terminal. You will need a node name for both the DECnet 
communications front end and the host or central processor. 

• Read the DECnet-20 BEWARE file if there is one. 
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• TOPS-20 Version 4 has a new operator command syntax and a new 
operator interface. You can successfully complete procedures 
by following the directions. However, you will be better 
prepared to handle unexpected situations if you are familiar 
with the new OPR-ORION facilities under GALAXY. 

• You will use both DUMPER and the batch subsystem during 
configuration. Depending on your experience, you may wish to 
review these programs. Commands that check your progress 
through the procedures may be helpful. 

• Set aside approximately two hours for your on-site 
configuration. (Actual time may be less or more, depending on 
you, the configuration, and your operating system.) Secure a 
terminal and location where you will not be interrupted. 



9.3 THE CONFIGURATION TOOLS AND RELATED FILES 

The term "configuration tools" refers to NETGEN, TKB20, VNP20, and 
DNMAC . 

Two standard TOPS-20 DUMPER-f ormatted magnetic tapes contain the files 
needed. The distribution tapes are the Task-to-Task Release Tape and 
the DN200 RJE Release Tape. (There is also a tape with unsupported 
software for customer use.) The tapes contain the same information for 
all systems with the same unbundled options. 

You must use the task-to-task tape to set up your system for 
task-to-task capability before you use the RJE tape (if this option is 
purchased) . 

The task-to-task tape contains all the files needed to support 
task-to-task capability for any configuration. Also included are the 
network control task (NETCON) and its associated loader files, and 
required .BWR, .HLP, and .DOC files. The major files and file types 
that are used to build your specific DECnet configuration are: 

• PDP-11 files for all modules needed for any configuration of 
the DN2x. This includes object modules, symbol tables, and 
memory maps. 

• DN20BLD.CMD. This is the command file for building a DN2x 
front end for single or multiple line task-to-task systems. 
(For single line task-to-task systems of 32K words, the 
comparable file is 32KBLD.CMD; for RJE the command file is 
DN200BLD.CMD.) When the commands in this file have been 
executed, your front-end directory will contain the following 
files : 

• BUILD-ALL. CTL. This is the control file for the batch 
job that follows the NETGEN program. 

• RSX11S.TSK. This file sets up the DN2x for the 
front-end memory image. 

• RSX11S.STB. This is the symbol table file for the 
front end. 

• DNMAC.EXE. This is the cross assembler for PDP-11 macro 
source files. 
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NETGEN.EXE. This is the program that allows you to enter 
parameters for your site. These parameters will be used to 
construct CETAB, the data base for the node you are 
configuring . 

TKB20.EXE. This program constructs PDP-11 formatted task 
images from object files. 

VNP20.EXE. This program creates the front-end system image. 



9.3.1 The NETGEN Program 

NETGEN is the interactive program that you use to describe 
hardware and software for the node you are configuring. 



the 



9.3.1.1 Features - NETGEN has default values for all values that you 
type in by command or in response to a prompt. Where these values 
represent the correct values for your configuration, you need only 
type carriage return. The program will assume the default for that 
parameter . 



If you type a ? following the NETGEN prompt 
responds with a list of valid commands. 



(NETGEN>) , the program 



NETGEN>? Command name, one of the following: 



CCBs Exclude 

Flow-count Help 

Logical-links Node 

Password RDB-size 

Save SDB-size 
Transmit-buf fers 
NETGEN> 



Exit 

Include 

NRM-pipes 

RDBs 

SDBs 



Finished 
Information 
Number -of -nodes 
Restore 
Software-ID 



Now you know the possible commands, but not the possible responses. 
NETGEN will continue to help you via the ? feature. Type the command 
you wish to give and press the space bar. Again type ?. For example: 

NETGEN>include ? Device type, one of the following: 
Card-reader DMC11 DTE20 DUP11 

KDP Line-printer Task 

NETGEN>include 



Assume you wish to inform NETGEN that your controller is a KDP. Type 
KDP. Never assume you have completed a command. Press the space bar 
and again type ?. The program responds with both a prompt for more 
information and the permissable range of values within which your 
response must fall. (Assuming the command has additional parameters 
to be entered) : 

NETGEN>include kdp ? KD P Number, to 2, decimal number 

NETGEN>include kdp CED 

Number of DUP11 lines on this KDP(l-4): 

In the last example you could also respond by typing KDP<ESC>. This 
would give you the guideword (number), but not the valid limits of the 
parameter. For example: 



( £ sc ) 



NETGEN>include kdp (number) 
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Using ? or <ESC> will not result in confusing messages. A typed 
<ESC> that has no purpose, that is, no further response is necessary, 
will have no effect. A ? typed when the command has been completed 
will result in the message shown below: 

NETGEN>include dupll (number) ? confirm with carriage return 

Recognition input (typing <ESC> to cause completion of commands and 
printing of guidewords) is available in NETGEN. This feature works 
the same for NETGEN commands as for TOPS-20 commands. The added 
information provided by the guidewords is even more helpful in NETGEN 
because the commands will not be familiar to you. In the following 
examples, the same three instructions require more than twice as many 
key strokes using full input rather than recognition input. As you 
read the recognition input, notice how the guidewords lead you to the 
correct response. 

Full input: 

NETGEN>PASSWORD RECEIVE MARL CUD 

NETGEN>SAVE PS : <DN20-1>NETGEN-CONFIG. IMAGE CUD 

Recognition input: 



( esc ) 



NETGEN>Flow-count (for DN200 links is) 14 C1JT) 



NETGEN>Password (for) Receive (is) MARLQID 

( ESC ) ( ESC ) 

NETGEN>Save (configuration on) PS: <DN20-1>NETGEN-CONFIG. IMAGE CmD 



9.3.1.2 NETGEN Terms and Concepts - To configure and install your 
TOP-20 DECnet-20 Version 2.0 subsystem you need to be familiar with 
certain components you will normally be aware of indirectly if at all. 
This section is to familiarize you with the hardware and software 
terms used in NETGEN. The actual values to be entered will be 
explained later in the step-by-step procedure. 

Hardware Terms: 

All hardware terms you supply to NETGEN are DECnet-20 specific and 
must be directly related to the node you are configuring. You do not 
include hardware attached to the console front end or hardware 
attached to a communications front end running DN6x software. 

DN20 The term DN20 is a generic term and includes 

both the DN20 and the DN21, that is, DN20 
refers to a DECnet-20 communications front 
end. 

KDP The term KDP is a DECnet term that refers to 

a combination of a KMC11 (controller) and one 
to four DUPlls. With the KMC the DUP11 
functions as a direct memory access device 
(DMA) . The interface is synchronous. The 
program prompts you for attached lines. 
DUPlls with a KMC are not specified 
separately with the INCLUDE command. 
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DUP11 



DMC11 



This term is used in the NETGEN program to 
indicate DUPlls running as a character 
interrupt device, that is, without a KMC11. 
A DUP11 may be specified in an INCLUDE 
command only when it exists without a KMC. 



The DMC11 is 
microprocessor -based 
network. The DMC11 
device. 



a single line 

interface to the 

is a synchronous DMA 



DTE 20 



The DTE20 referred to in the program is the 
interface between the 2040, 2050, or 2060 
processor and the DN20 front end. The 
parameter to be supplied to the program for 
the DTE20 is the number by which the software 
identifies the DTE, not the number of DTEs. 
Since DTE is (and must be) the DTE that 
connects the console front end with the main 
processor, the parameter to be supplied will 
usually be DTE 1. The exception will be the 
case where your configuration has a front end 
for IBM Emulation/Termination. The two 
communication front end interfaces to the 
main processor would be DTE 1 and DTE 2. 
Provided the data base contains the valid 
number, it does not matter which is 1 and 
which is 2. 



Links 



Node 



Line-printer 
Card-reader 



Software Terms: 



This term appears in response to the 
INFORMATION command. The value is 
established by the program and not by a 
command you type. Links refers to the total 
number of physical links present in your 
DECnet-20 subsystem. If you have a KDP with 
two lines, for example, you have 3 links: 
one link controlled by DTE 1 to the main 
processor, one link with the identification 
KDP_0_0, and one link with the identification 
KDP_0_1 . 

Used as a command, this term refers to your 
DECsystem-20 communications front end (or the 
DN200 if you are configuring for RJE) . The 
NODE command takes several arguments. As 
used in the command NUMBER-OF-NODES , the 
reference is to the number of task-to-task 
links plus 2 (allowance for expansion of the 
network) ." 

Line printer and card-reader parameters are 
normally specified for the DN200 
configuration only. (If you believe you have 
one or more of these devices on the DN20 when 
you do not have RJE, check with your 
manager . ) 



The NETGEN program introduces software terms (several of which are 
acronyms) that may not be familiar to you. Or, you may be familiar 
with the terms but unaware of the significance of the parameters you 
enter associated with the terms. 
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The default values associated with the software terms will be 
acceptable in most instances. You can, however, alter the default 
values to tailor your DECnet system to your particular needs. Any 
changes you make in the values must fall within the limits set by the 
program. Do not change default values if you do not fully understand 
the implications of the change. 

The software terms are explained in the order in which they would 
normally be entered or displayed. The format used is the command 
format unless the term is displayed only. 

Node Name This is the name for the node being generated. 

Within the network the node name must be unique. 
In the next release it will be a requirement that 
the node name include at least 1 alpha character. 
You may wish to meet this requirement during this 
generation. 

Node Number This term refers to the node identifying number. 

It may be any decimal number in the range 2 to 127 
provided it does not duplicate a number already 
assigned to another node in the network. Node 
names and node numbers must be unique to establish 
the identify of a node in a unambiguous manner 
when the name or number is used in a command by 
the local or remote node. 

Node Type Node type must be either DN20 or DN200. DN20 is 

valid for task-to-task capability. DN200 is valid 
for RJE. 

Software-ID This term identifies the software you are 

including as your DECnet subsystem. Any text 
string from 1 to 32 characters is valid. 

Password Transmit This is the password sent to the remote node 

during an NSP initialization sequence. This is an 
optional parameter. If given, the transmit 
password must be a text string of 0-8 characters. 

Password Receive If specified, this password must be sent by the 

remote node during an NSP node initialization 
sequence. The receive password must be a text 
string of 0-8 characters. The receive password is 
optional. The default is null. 

Logical-links This term refers to the number of logical links 

NSP should support. Included are the logical 
links for user tasks and utilities. Be sure to 
include logical links for file transfer. The 
permitted range is 12-63; the default is 24. The 
cost of additional logical links is more memory 
for more speed. 

CCBs This term is the acronym for Communication Control 

Blocks. The CCBs command sets the number of CCBs. 
CCBs contain pointers to SDBs. The number of CCBs 
must be at least as large as the number of SDBs. 
The permitted range is 10-200; the default is 64. 
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RDBs This term is the acronym for Receive Data Buffers. 

RDBs are used for both transmitting and receiving 
data segments. The RDBs command sets the number 
of RDBs. When the number of simultaneous 
exchanges between nodes exceeds the number of 
RDBs, a delay will occur before transmission can 
be made. This parameter depends on the 
configuration of your network and the extent and 
nature of your network activities. Factors to 
consider are: number of nodes; number of users; 
the mix of interactive jobs to file transfer; 
peak and average load; and the limits set by 
available memory. More RDBs improve throughput at 
the expense of memory. The permitted range is 
6-200; the default is 64. 

RDB-size This term refers to the size of the RDBs in bytes. 

The size of the RDB determines the largest network 
data segment your system can transmit or receive 
via the physical line protocol (DDCMP) . Large 
buffer size is best for file transfer service; 
small buffer size (and hence more buffers) is best 
for interactive traffic. The permitted range is 
290-2082; the default is 290. 

SDBs This term is the acronym for Small Data Buffers. 

The SDBs command sets the number of SDBs. SDBs 
are used for internal storage of transmit data and 
temporary data structures. The number of SDBs 
that can be used at one time is limited to the 
number of CCBs you specify. The permitted range 
is 8-63; the default is 32. 

SDB-size This term refers to the size in bytes of the SDBs. 

The permitted range is 80-128. The default is 80. 
SDB size, within the given limits, will have no 
appreciable effect on performance. 

Transmit-buf fers The number of Transmit buffers specified 

determines the number of transmit requests that 
NSP will try to keep outstanding. The permitted 
range is 2-16; the default is 2. The tradeoff is 
more memory for more speed. Double buffering is 
generally acceptable. 

Number-of-nodes This term refers to the number of nodes in the 

same network as the node you are configuring plus 
2 to allow for expansion. The permitted range is 
8-20; the default is 12. The number-of-nodes 
must be at least equal to the maximum number of 
lines plus 2. 

NRM Pipes 

NRM Flow Count The defaults currently set are adequate. Allow 

these parameters to be defaulted. 



Estimated -Pool -Size 



This parameter is calculated by the program and 
appears only in response to the INFORMATION 
command. Pool-size is calculated on the basis of 
your specified configuration. 
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9.4 CONFIGURING FOR TASK-TO-TASK CAPABILITY 

Files on the Task-to-Task Release Tape include all files that are 
needed to provide task-to-task capability for any DECSYSTEM-2020 , 
2040, 2050, or 2060. The DN20 files on tape are located in the 
directory PS:<DNGEN> and the subdirectory PS: <DNGEN.CMDS> . You create 
identical directories on your system and then copy the entire contents 
of the two directories to your system. These two directories should 
be saved as copied. In addition, if you are running a DECSYSTEM-2040 , 
2050, or 2060, you create a separate directory that will contain only 
those files specific to the DN20 system that you are generating. This 
directory is PS:<DN20-1>. 

Once the directories are created and the files are restored from tape, 
you proceed with the several steps that build the DN20 front end. The 
parameters that appear in example commands have been chosen to ensure 
an efficient procedure: space parameters allow for expansion and 
actual and logical names permit inter-file referencing. You should 
not experience needless delays if you follow the directions exactly. 

If you are upgrading from a previous version, use <NEW-SYSTEM> and 
<NEW-SUBSYS> for the directories <SYSTEM> and <SUBSYS> respectively. 
Files from the current version of the distribution tape should be 
copied to empty directories, that is, not mixed with files of a prior 
version. (The previous version should be saved on tape or disk until 
the current version runs successfully in a normal working 
environment. ) 

Because command and control files and logical definitions reference 
other files, you should name and locate files as given in the text and 
examples. If indicated by your site's conventions, file names and 
locations may be changed after the configuration and installation 
procedures have been successfully completed. Be aware, however, that 
should you later wish to reconfigure the system or run validation or 
certification tests for diagnostic purposes, references to files and 
structures will need to be resolved. 

A fully installed TOPS-20 operating system with a monitor that is 
Version 4.0 or later is a prerequisite to on-site configuration of the 
DN20. Log in as a user with OPERATOR or WHEEL privileges and continue 
from Step 1 for DECSYSTEMs-2040/50/60, or from Step 4 for 
DECSYSTEM-2020. 

Step 1: Create PS:<DNGEN>. (DECSYSTEMs-2040/50/60 only) 

Enter : 



@ENABLEQeD 

$~ECREATE PS:<DNGEN>CHD 

[New] 

$$WORKING 1000CHD 

$$PERMANENT lOOO O^O 

$$PROTECTION 774000Qe7) 

$$PASSWORD DECNETQiD 

$$DIRECT 4747GID 

$$USER 4747QJ1D 

$$ MAXI MUM IQeT) 

$$dD 

SDISABLE C^D 



9-10 



USING THE CONFIGURATION TOOLS 

Step 2: Create PS : <DNGEN.CMDS> . (DECSYSTEMs-2040/50/60 only) 

Enter : 

@ENABLEQeD 

$~ECREATE PS:<DNGEN.CMDS> CrIP ) 

[New] 

$$WORKING 150QID 

$$PERMANENT 150 (^0 

$$PROTECTION 774000QID 
$$DIRECT 4747Q1D 
$$FILES-ONLYQiD 

$$CmD 
$disableqid 

Step 3: Create PS:<DN20-1>. (DECSYSTEMs-2040/50/60 only) 
Enter : 

@ENABLEdD 

Recreate ps:<dn20-i>GOD 

[New] 

$$WORK 750QJD 

$$PERM 750(^0 

$$USER 4747fiiD 

$$PASSWORD XXXC^D 

$$ ( RET ) 

$DISABLEQeD 

<§ 

The password to the front-end directory (PS: <DN20-1>) to be built may 
be your own password for logging in to PS:. 

Step 4: Create PS:<DECNET> 
Enter: 



opmi rj 



Recreate ps:<decnet>QID 

[New] 

$$W0RK 2000CHD 
$$PERM 2000 CE*D 
$$PROTECTION 774000 CUD 
$$USER 4747QID 
$$PASSWORD XXX GE) 

$DISABLEGeT) 
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Step 5: Create PS: <UETP.DECNET> . 
Enter : 

@enableq!d 

Recreate ps:<uetp.decnet>CE£i 

[New] 

$$WORK 100 CUD 

$$PERM 100QID 

$$files-onlyGE) 

$$USER 100CE1D 
$$DIRECT 4747QlD 

$$C«D 

$DISABLEQtT} 



Step 6: Use DUMPER to restore files from tape to disk. Mount the 
DECnet Version 2 distribution tape on an available drive. (MTAO or 
MTO is used in the examples.) If you are running a DECSYSTEM-2020 , 
complete Step 6 and continue with Chapter 10. 

NOTE 

Restoring the save sets not related to 

configuring the front end is done at 

this time to avoid a second handling of 
the tape. 

Use the INFORMATION SYSTEM-STATUS command to determine if tape 
allocation is enabled for your system. 

If your installation does not include the tape allocation enabled 
feature :- 

Enter: 



PENABLE C t" ) 
$ASSIGN MTA0:CHD 

$DUMPERCED 
DUMPER>TAPE MTA0:C^Q 
DUMPER>REWINDQeD 



I 

DUMPER>ACCOUNT (OF RESTORED FILES FROM) SYSTEM-DEFAULT CrTQ 

( ESC ) ( ESC ) 

DUMPER>RESTORE (TAPE FILES) PS: <*>*.*.* (TO) <DECNET>Qe?) 
(Restores Documentation files.) 

( Ei * ) ( ESC ) 
I \ 

DUMPER>RESTORE (TAPE FILES) PS: <*>*.*.* (TO) <SUBSYS>QID 
(Restores Binary files.) 

C5T) ( ESC ) 

DUMPER>RESTORE (TAPE FILES) PS: <*>*.*.* (TO) < DECNET > ( "ret ) 
(Restores Source files.) 



9-12 



USING THE CONFIGURATION TOOLS 



NOTE 

The next RESTORE command is for 
DECSYSTEMs-2040/50/60 only. 



GED 

DUMPER>RESTORE (TAPE FILES) PS : <DNGEN> , PS : <DNGEN. C MPS > C*iD 
(Restores DN20 Generation files) 

COD CIO 

DUMPER>RESTORE (TAPE FILES) PS:<*>*.*.* (TO) <UETP . LIB>C^T 
(Restores the acceptance files.) 



(ESC J ^ ESC ) 

DUMPERXRESTORE (TAPE FILES) PS:<*>*.*.* (TO) <UETP. DECNET> Cml 

(Restores the sample files for acceptance tests.) 

DUMPER>REWINDQe7^ 

DUMPER>EXIT f^p 

$DISABLEQiD 



Or if your installation includes the tape allocation enabled feature 
Enter : 

@ENABLECh7) 

$MOUNT TAPE logical-name : Q1D 

[logical name: assigned to MTO] 

NOTE 

If you are working standalone and there 
is no operator in attendance, go to the 
operator's console and enter the 
IDENTIFY command: 

OPR> IDENTIFY tape-id REQ request-id 

The request-id appears on the operator's 
console. The tape-id you type is MTAn. 
The system associates the physical 
device MTAn with your logical assignment 
to MTn. 
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$dumperQ£D 

DUMPER>TAPE logical-name : CUD 
DUMPER>REWIND Q[T) 

DUMPER>ACCOUNT (OF RESTORED FILES FROM) SYSTEM-DEFAULT Qet 



CiD ® 

DUMPER> RESTORE (TAPE FILES) PS:<*>*.*.* (TO) <DECNET>QeD 
(Restores Documentation files.) 



ESC ) ( ESC ) 

DUMPER>RESTORE (TAPE FILES) PS:<*>*.*.* (TO) <SUBSYS> C^T) 
(Restores Binary files.) 

( ESC ^ ( ESC ) 

* T / x 

DUMPER>RESTORE (TAPE FILES) PS:<*>*.*.* (TO) <DECNET>C^O 
(Restores Source files.) 



NOTE 

The next RESTORE command is for 
DECSYSTEMs-2040/50/60 only. 



C E SC ) 

DUMPER> RESTORE (TAPE FILES) PS : <DNGEN> , PS ; <DNGEN.CMDS> C^~) 
(Restores DN20 Generation files) 

( ESC ) ( ESC ) 

DUMPER>RESTORE (TAPE FILES) PS:<*>*.*.* (TO) <UETP . LIB> QeT) 
(Restores the acceptance files.) 



ESC 

DUMPER>RESTORE (TAPE FILES) PS:<*>*.*.* (TO) <UETP . DECNET>QeT) 

(Restores the sample files for acceptance tests.) 

DUMPER> REWI ND C^O 

DUMPER>EXITQeT) 

$DISMOUNT TAPE logical name CUD 

$DISABLE G^T) 



The logical name used above may be your first or last name, or any 
other valid string you will remember. If you are installing a 
DECSYSTEM-2020, go to Chapter 10 now. 
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Step 7: Set up the build files. 
Enter : 

@DEFINE GEN: PS : <DNGEN> , PS : <DNGEN. CMDS> QID 



This command defines the location of the release distribution 
areas. 

©DEFINE DN20: PS : <DN20-1> C^T) 

This command defines the front-end directory created for 
site-specific files. 

©DEFINE DSK: DSK : ,GEN : CElD 

This command defines the file search association of DSK: 

Step 8: CONNECT to DN20: and establish group privileges by 
performing an ACCESS. 

Enter : 

©CONNECT DN20:QiD 
Password: XXX 
©ACCESS DN20: f^T ) 
Password: XXX 

The password is the same as that used in Step 3. 

Step 9: Tell the system to process the command file appropriate for 
your configuration. 

With this step you begin work on configuration. From this point on 
files will be put to the directory <DN20-1>. Therefore, a failure in 
generation procedures may require that all files be deleted from 
<DN20-1> and that you repeat all from Step 9. 

If you are configuring a multiline task-to-task system with or without 
the RJE option or a single line task-to-task system with more than 32K 
of memory: 

Enter : 

©TAKE DN2 0BLD.CMDQiD 



If you are configuring a single line task-to-task system with only 32K 
of memory: 

Enter: 

©TAKE 32KBLD.CMD(~^0 
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The following files are now in the DN20: directory, PS:<DN20-1>: 

BUILD-ALL. CTL.l (control file for the Batch job that follows 

NETGEN) 

RSX11S.STB (symbol definition file) 

RSX11S.TSK (task image file) 

If you use the wrong file in this step, simply repeat the TAKE command 
using the correct file. 

Step 10: Run the NETGEN program to define the system configuration. 

Enter : 

flnetgen C ret ) 

TOPS-20 Network Configuration for DN2x or DN200, Version: V2.2-39 

NOTE 

If you are configuring a 32K DECnet-20 
communications front end and have 
neglected to read the file DECNET.BWR. 1, 
do so now before you continue. Within 
the beware file there is a memo with the 
subject title "Configuration of Release 
4 32Kw DN20s". The beware file may be 
printed or typed from 
FS:<DECNET>DECNET.BWR.l (unless you 
elected to put the documentation save 
set in a different directory) . 

Step 10.1: Give the identifying parameters for your DN20. The 
following is an example entry. 



Enter : 



NETGEN>node name marlQ|7) 
NETGEN>node number 67 ( ret ) 
NETGEN>node type DN2 C »" ) 



NOTE 

You could have taken advantage of NETGEN 
features by using any of the following 
for help: 
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NETGEN> ? Command name, one of the following: 
CCBs Exclude Exit Finished 

Flow-count Help Include Information 

Logical-links Node NRM-pipes Number-of-nodes 

Password RDB-size RDBs Restore 

Save SDB-size SDBs Software-ID 

Transmit-buf fers 

NETGEN>node ? Parameter, one of the following: 
name number ty pe 

NETGEN>node name marl C *et ) 

NETGEN>node number fi7 ( " ET ) 

NETGEN>node type ? Node type, one of the following: 
DN20 DN200 

NETGEN>node type DN20QeT) 

NETGEN> 

You may need to use the <ESC> and ? in 
later commands. They will not always be 
given in examples. If you need more 
help with a parameter or command, refer 
back to Section 9.3.1.1. 

You are now ready to examine the default values and accept them or 
change them to reflect your planned configuration. 

Step 10.2: Check the current parameters. 

NETGEN>infoQID 

Node name is: MARL 

Node number is: 67 

Software ID is: DECnet-20 V2 

Transmit Password is: DECNET20 (default) 

Receive Password is: (null) (default) 

Logical links: 24 (default) 

CCBs: 64 (default) 

RDBs: 64 (default) 

RDB-size: 290 (default) 

SDBs: 32 (default) 

SDB-size 80 (default) 

Transmit buffers: 2 (default) 

Node type is: DN20 

Number of nodes: 12 (default) 

KDPs: 1 (default) 

KDP_0 has 1 lines, 

DUPlls: (default) 

DMClls: (default) 

Physical links: 2 (default) 
NSP link controlled by DTE_1, Task-to-Task 
NSP link controlled by KDP_0_0 , Task-to-Task 

DTE20 number: 1 (default) 

Line printers: (default) 

CRlls: (default) 

Tasks: (defaulted) 

72-Hour-Test 
Topology-Notif ier 

NRM pipes: 3 (default) 

NRM Flow-count: 16 (default) 

Estimated Pool-size: 5504 bytes 
NETGEN> 

Step 10.3: Adjust the current hardware parameters as required by the 
hardware at your site. 
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Example #1. To include 3 lines controlled by the KDP, rather than the 
1 indicated. 

Enter : 

NETGEN>exclude kdp 0® 

NETGEN>include kdp CUD 

Number of DUP11 lines on this KDP(l-4) : 3 

NETGEN> 

The KDP is first excluded and then included to permit you to specify 
the changed number of lines and trigger the correct number of prompts 
for link usage. 

Example #2. To include 3 DMClls and no KDPs. 

Enter : 

NETGEN>exclude kdp OQID 
NETGEN>include dmcll CED 
NETGENHnclude dmcll 1 CUD 
NETGEN>include dmcll 2 QED 
NETGEN> 

Step 10.4: Check all current parameters. (The output shown assumes 
input as in Example 2.) 



Enter : 



NETGEN>informationC^T) 

Node name is: MARL 

Node number is: 67 

Software ID is: DECnet -20 V2 

Transmit Password is: DECNET20 (default) 

Receive Password is: (null) (default) 

Logical links: 24 (default) 

CCBs: 64 (default) 

RDBs: 64 (default) 

RDB-size: 290 (default) 

SDBs: 32 (default) 

SDB-size 80 (default) 

Transmit buffers: 2 (default) 

Node type is: DN20 

Number of nodes: 12 (default) 

KDPs: 

DUPlls: (default) 

DMClls: 3 

Physical links: 4 
NSP link controlled by DTE_1 , Task-to-Task 
NSP link controlled by DMC11_0, Task-to-Task 
NSP link controlled by DMC11_1, Task-to-Task 
NSP link controlled by DMC11_2, Task-to-Task 

DTE20 number: 1 (default) 

Line printers: (default) 

CRlls: (default) 

Tasks: (defaulted) 

72-Hour-Test 
Topology-Notif ier 

NRM pipes: 3 (default) 

NRM Flow-count: 16 (default) 

Estimated Pool-size: 5504 bytes 
NETGEN> 
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Step 10.5: Make necessary additions and any desired changes in 
parameters. The default parameters for software should be 
adequate for the two examples. Space permitting, you may 
wish to increase the number of CCBs, SDBs, RDBs, and 
logical links for the configuration with the three higher 
speed DMClls. 

If you are configuring a system with 32K, you must exclude either the 
72-Hour-Test or the Topolology-Not if ier . 

Possible entries, depending on the network you plan, might be: 



NETGEN>password *(for) ? Password type, one of the following: 
Receive Transmit 



NETGEN>password (for) receive (is) ? Receive password, to 8 characters, text string 



NETGEN>password (for) receive (is) GUESTQI 



cp cp 

NETGEN>password (for) transmit (is) MARL67f^T 



********* 



NETGEN>exclude (from Configuration) task (type) ? task type, one of the following: 
72-Hour-Test Operator-Console Topology-Notification 

NETGEN>exclude (from Configuration) task (type) 72-Hour -Test QID 
NETGEN> 



********* 
NETGEN>ccbs ? Number of CCBs, 10 to 200, decimal number 
NETGEN>ccbs 96QED 

NETGEN>sdbs ? Number of SDBs, 8 to 63, decimal number 
NETGEN>sdbs 40QiD 

NETGEN>rdbs ? Number of RDBs, 6 to 200, decimal number 
NETGEN>rdbs 96(~^P) 
NETGEN> 
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Step 10.6: Examine the current parameters once again if you made any 
entries since Step 10.4. 

The example below assumes you have added MARL67 and GUEST as the 
transmit and receive passwords, respectively, rather than accept the 
defaults. 

Entry and response: 

NETGEN> information OFT) 

Node name is: MARL 

Node number is: 67 

Software ID is: DECnet -20 V2 

Transmit Password is: marl67 

Receive Password is: guest 

Logical links: 24 (default) 

CCBs: 64 (default) 

RDBs: 64 (default) 

RDB-size: 290 (default) 

SDBs: 32 (default) 

SDB-size: 80 (default) 

Transmit buffers: 2 (default) 

Node type is: DN20 

Number of nodes: 12 (default) 

KDPs: 

DUPlls: (default) 

DMClls: 3 

Physical links: 4 
NSP link controlled by DTE_1, Task-to-Task 
NSP link controlled by DMC11_0, Task-to-Task 
NSP link controlled by DMCll_l f Task-to-Task 
NSP link controlled by DMC11_2, Task-to-Task 

DTE20 number: 1 (default) 

Line printers: (default) 

CRlls: (default) 

Tasks: (defaulted) 

72-Hour-Test 
Topology-Notif ier 

NRM pipes: 3 (default) 

NRM Flow-count: 16 (default) 

Estimated Pool-size: 5504 bytes 
NETGEN> 

Step 10.7: When the output from the INFORMATION command accurately 
reflects what you want your configuration to be, save the 
completed NETGEN procedure. Check very carefully: Once 
you have typed "FINISHED", correction procedures will 
include returning to Step 9 or less. 

Enter: 

NETGEN>save ? output filespec 



NETGEN>save ps : <DN20-1>NETGEN-CONFIG. IMAGEQet 



(Typing escape results in the output NETGEN-CONFIG. IMAGE 
as the default file name.) 
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Step 10.8: Type the commands FINISHED and EXIT. 

Enter : 

NETGEN>f in i shed C^> 

%Have you issued a SAVE command for this configuration? 

NETGEN>exit(7TP) 

@ 

(The reminder above, given after you type finished, is given ONLY 
if you did NOT save the completed NETGEN procedure. The reminder 
would not appear if Step 10.7 had been executed as given.) 

The following files are now in your connected directory: 

BUILD-ALL. CTL.l 

CETAB.MAC.l 

GBLDLX.MAC.l 

GBLFLO.MAC.l 

GBLNSP.MAC.l 

NETGEN-CONFIG . IMAGE . 1 

NRMDAT.MAC.l 

RSX11S.STB. 1 

RSX11S.TSK.1 

Step 11: Ensure that the DN20 directory contains only the necessary 
files. 

If the system notifies you that deleted files will be expunged, do NOT 
begin the following sequence. Wait until the expunge is completed. 
(The undelete will not function if the files have been expunged.) 

Enter : 

©delete *.*QeT) 
@undel rsxlls. * (~rTP) 
@undel *. image ( ret ) 
@undel *.mac ( ret ) 
@undel build -all . ctl pET ) 

Step 12: Submit the BUILD-ALL. CTL file to the batch system. 

Enter : 

©SUBMIT BUILD-ALL. CTL/TIME: 15/OUTPUT : NOLOG/NOTIFY : YES QtT) 
[Job BUILD Queued, Request-ID #60 Limit 00:15:00] 

The batch job should take from 10 to 15 minutes. When the job is 
completed, the system will output the equivalent of: 

[From SYSTEM: Job BUILD Request # 60 Finished Executing at 14:47:31] 
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Step 13: Type or print the BUILD-ALL.LOG file and examine the file 
for errors. 

Interpret Batch system messages as follows: 

? at the start of the message indicates a fatal error. 

% at the start of a message indicates a warning. 

[ at the beginning of a message indicates a comment. 

Following successful completion of the Batch job, all files that are 
needed to construct the actual system have been created. Only jobs 
with fatal errors have failed to complete successfully. Warning 
messages may appear for any given configuration. Undefined global 
symbols, default symbols generated, and possibly multiply-defined 
global symbols may require no action on your part. All fatal errors 
require repetition of some previous steps. Interpret the fatal error 
message given to determine the steps to be repeated. (See Appendix G 
for a complete list of error messages for TKB20 and VNP20.) Consult 
your Software Support Specialist if you are in doubt as to how to 
proceed . 

Step 14: Run the VNP20 program. 
Enter: 

@VNP20QifD 
This program runs in approximately 2 minutes of CPU time. 

When VNP20 completes successfully, the following output appears on 
your terminal: 

• information on free space within the core image, the kernel 
pool, and the network pool 

• a partition map of the created system front-end image 

Your system now includes basic task-to-task capability. To include 
the RJE option, continue with Section 9.5. If you are generating a 
system without the RJE option, go now to Chapter 10. 

IN CASE OF ERRORS: 

If errors prevent successful completion of a step in the configuration 
process, check all steps prior to the point of failure. Specifically 
check if user groups were set correctly in Steps 1, 2, and 3, and if 
the access command was correctly executed in Step 6. If you have not 
found your error, check Step 9. Did you use the correct file for the 
TAKE command? If so, next check the files that should be in the DN20 
directory at the end of Step 9 and at the end of Step 10.8. If an 
error has not been found, check the NETGEN procedure for omissions or 
errors and the BUILD-ALL.LOG file for error messages preceded by "?" . 
If a fatal error is found in the log file, delete the log file. Go 
back to the point of error and repeat all from that point. 
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9.5 CONFIGURING FOR REMOTE JOB ENTRY 

To build the DN200 image you follow the same logical steps you 
followed to build the DN20. However, because of the differences in 
hardware and functions, there will be some differences in files used 
and values you specify. These differences will be given under the 
step number when they occur. 

In all instances the name DN20 becomes DN200. 

Steps 1 and 2. (Creation of directories.) 

You have already created the directories PS:<DNGEN> and 
PS:<DNGEN.CMDS>. The additional files needed for the DN200 
configuration will be added to these directories. 

Step 3: Create PS:<DN200>. 

Enter : 

@ENABLEQeT) 

Recreate ps:<dn200>cED 

[New] 

$$WORK 750QeD 
$$PERM 750QED 
$$USER 4747QED 

$$ PASSWORD xxx CHE) 

$DISABLE CED 

The password to the DN200 directory to be built may be your own 
password for logging in to PS:. 

Step 4: Use DUMPER to restore files from tape to disk. 

The input tape is the DN200 RJE Release Tape. 

If your installation does not include the tape allocation feature: 

Enter : 



(a ENABLE (het 

$ASSIGN MTAOQED 
SDUMPER C^O 
DUMPER>TAPE MTAOQH 
DUMPER> REWIND f^T) 



( £ sc ) 



DUMPER>ACCOUNT (OF RESTORED FILES FROM) SYSTEM-DEFAULTL^ 



( esc ) 

DUMPER> RESTORE (TAPE FILES) PS:<*>*.*.* (TO) <DECNET>C»» ) 
(Restores Documentation files.) 

DUMPER>RESTORE (TAPE FILES) PS : <DNGEN> , PS : <TDNGEN.CMDS> Gil 
(Restores DN2 00 G eneration files) 

DUMPER> REWIND QED 
DUMPER>EXITQeT) 

$ DISABLE GET) 
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Or, if your installation includes the tape allocation feature 

Enter : 

@ENABLE CeD 

$MOUNT TAPE logical name: CUD 

[logical name: defined as MTO:] 



NOTE 

If you are working standalone and there 
is no operator in attendance, go to the 
operator's console and enter the 
IDENTIFY command: 

OPR>IDENTIFY tape-id REQ request-id 

The request-id appears on the operator's 
console. The tape-id you type is MTAn. 
The system associates the physical 
device MTAn with your logical assignment 
to MTn. 



$DUMPER GOD 

DUMPER>TAPE logical name : f^P 

DUMPER>REWIND Qh3 

( ESC ) 

\ 

DUMPER>ACCOUNT (OF RESTORED FILES FROM) SYSTEM-DEFAULT C^l 

Gp c esc ) 

DUMPER>RESTORE (TAPE FILES) PS :<*>*.*.* (TO) <DECNET>QID 
(Restores Documentation files.) 

Gp 

DUMPER>RESTORE (TAPE FILES) PS : <DNGEN> , PS : <DNGEN.CMDS>GH 

(Restores DN2 0Q G eneration files) 

DUMPER>REWIND QED 

DUMPER>EXIT f^Q 

$DISMOUNT TAPE logical name© 

$DISABLEQED 



Step 5: Set up the build files. 

Enter: 

@DEFINE GEN: PS : <DNGEN> , PS : <DNGEN. CMDS>QE 
@DEFINE DN200: PS : <DN200> (~^P 
@DEFINE DSK: DSK:,GEN:QiD 
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Step 6: CONNECT to DN200: and establish group privileges by 
performing an ACCESS. 

Entry and response: 

^CONNECT DN200:QlD 
Password: xxx 
@ACCESS DN200:QED 
Password: xxx 

Step 7: Tell the system to process the appropriate command file. 

Your work on configuration begins with this step. As was noted in 
configuring the DN20, a failure in procedures from this point on may 
require that existing files be deleted from <DN200> and that you 
repeat all from Step 7. 

Enter : 

(STAKE DN200BLD.CMDQID 

Step 8: Run the NETGEN program to define the DN200 configuration. 

Enter : 

@NETGENQ!D 

TOPS-20 Network Configurator for DN2x or DN20G, Version: V2.2-39 

Step 8.1: Give the identifying parameters for the system. 

Enter : 

NETGEN>node name mar200_CpD 
NETGEN>node number 68 ( ret ) 
NETGEN>node type dn200 O^P ) 
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Step 8.2: Check the current parameters. 

Enter : 

NETGEN>infoQtT) 

Node name is: MAR200 

Node number is: 68 

Software ID is: DECnet -20 V2 

Transmit Password is: DECNET20 (default) 

Receive Password is: (null) (default) 

Logical links: 17 (default) 

CCBs: 30 (default) 

RDBs: 20 (default) 

RDB-size: 290 (default) 

SDBs: 15 (default) 

SDB-size: 80 (default) 

Transmit buffers: 2 (default) 

Node type is: DN200 

Number of nodes: 12 (default) 

KDPs: (default) 

DUPlls: (default) 

DMClls: 1 (default) 

Physical links: 1 (default) 

NSP link controlled by DMC11_0, Task-to-Task 
No DTE20 (default) 

Line printers: 1 (default) 

Line Printer #0 is an LP11 
CRlls: (default) 

Tasks: (defaulted) 

Operator -Console 
NRM pipes: 6 (default) 
NRM Flow-count: 4 (default) 
Estimated Pool-size: 3320 bytes 
NETGEN> 

Note that the program has adjusted the default parameters to values 
that probably will be most common to DN200 configurations. 

Step 8.3: Adjust the hardware parameters as required by hardware at 
your site. 

Possible additions/changes (ensure that your site requires or desires 
them) might be: 

To include a card reader 

Enter : 

NETGEN> include card-reader QED 
To exclude the printer 
Enter : 

NETGEN>exclude line-pr inter QeT) 
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To add a receive password, change the transmit password, or both 
Enter : 

Gp 

NETGEN> password transmit (is) MR200 f^P ) 



Gp 



NETGEN> password receive (is) TOMRGilD 

(Use of passwords in communication between the front end and the 
remote station is not a DECnet-20 requirement but is an option.) 

Step 8.4: Check all current parameters if you made any changes or 
additions. (The output shown assumes a card reader was 
added and transmit and receive passwords specified.) 

Enter : 

NETGEN>infoQlD 

Node name is: MAR200 

Node number is: 68 

Software ID is: DECnet -20 V2 
Transmit Password is: MR200 

Receive Password is: TOMR 

Logical links: 17 (default) 

CCBs: 30 (default) 

RDBs: 20 (default) 

RDB-size: 290 (default) 

SDBs: 15 (default) 

SDB-size: 80 (default) 

Transmit buffer: 2 (default) 

Node type is: y DN200 

Number of nodes: 12 (default) 

KDPs: (default) 

DUPlls: (default) 

DMClls: 1 (default) 

NSP link controlled by DMC11_0, Task-to-Task 
No DTE20 (default) 

Line printers: 1 
CRlls: 1 

Tasks: (defaulted) 

Operator -Console 
NRM pipes: 6 (default) 
NRM Flow-count: 4 (default) 
Estimated Pool-size: 3320 bytes 
NETGEN> 



Step 8.5: When the output from the INFORMATION command accurately 
reflects your configuration, save the completed NETGEN 
procedure . 

Enter: 



NETGEN>save PS : <DN200>NETGEN-CONFIG. IMAGE C^ 
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Step 8.6: Type the commands FINISHED and EXIT. 

Enter : 

NETGEN>f in i shed C^FP) 
NETGEN>exit flTT) 



Step 9: Ensure that the DN200 directory contains only the necessary 
files. 

If the system notifies you that deleted files will be expunged, do NOT 
begin the following sequence. Wait until the expunge is completed. 
(The undelete will not function if the files have been expunged.) 

Enter: 



@delete * . * ( ret ) 

@undel rsxlls. * QID 
@undel *. image ( ret ) 
@undel * .mac C"re"P) 
@undel build-all .ctl ( ret ) 

Step 10: Submit the BUILD-ALL. CTL file to the Batch system. 

Entry and response: 

@SUBMIT BUILD-ALL. CTL/TIME: 1 5/OUTPUT : NOLOG/NOTIFY : YES Q»D 
[Job BUILD Queued, Request-ID #61 Limit 15:00:00] 

Step 11: Type or print the BUILD-ALL.LOG file and examine the file 
for errors. 

Step 12: Run the VNP20 program. 

NOTE 

Be sure that you have configured ALL 
nodes. If, for example, you have 3 
DN200s in your configuration, you run 
NETGEN once for the DN20 front end and 
once for each of the DN200s. (Each node 
requires its own communications data 
base. ) 
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CHAPTER 10 
INSTALLING DECnet-20 



If you are installing a DECSYSTEM-2020 , go to Section 10.1. If you 
are installing a DECSYSTEM-2040/50/60 , continue with the next 
paragraph. 

Following the configuration of the DECnet-20 Version 2 (2040/50/60) 
system, you have only a few critical but simple entries to make: 

• Set up the DECnet Software by copying several files from 
PS:<DNGEN> to PS:<SUBSYS>, and one site-specific front-end 
file, nodename.SYS from PS:<DN20-1> to 
PS: <SUBSYS>norJpnanie. SYS. (Tf you configurer! a DN200,- also 
copy the PS: <DN200>nodename.SYS J file to 
PS: <SURSYS>, nodename.SYS, ) 



Locate and check the file SYSJOB.RUN on 
this file if there are missing entries. 



PS:<SYSTEM>. 



Edit 



Locate and check the file 4-CONFIG.CMD on PS:<SYSTEM>. Edit 
this file to include the NODE nodename nodenumber command. 

Locate and check the PTYCON.ATO file on PS:<SYSTEM> to include 
starting the NETCON program. 

Create an NCP.CMD file. 

Create a DN200.CMD file (if your system includes a DN200) . 



10.1 INSTALLATION PROCEDURE 



NOTE 

If you are updating your system from 
TOPS-20 V3A DECnet VI to TOPS-20 V4 
DECnet V2 , commands with 
structure/directory PS:<SYSTEM> and 
PS:<SUBSYS> should be interpreted as 
PS:<NEW-SYSTEM> and PS : <NEW-SUBSYS> . 
You follow the same procedure that you 
used to install TOPS-20 V4 . When the 
new versions of TOPS-20 and DECnet are 
performing satisfactorily, the old 
versions can be saved and <NEW-SYSTEM> 
and <NEW-SUBSYS> can be copied to 
<SYSTEM> and <SUBSYS> respectively. 



10-1 



INSTALLING DECnet-20 

All text and examples assume that your directories conform to the 
following conventions regarding contents: 

PS:<SYSTEM> for original installation 

or PS:<NEW-SYSTEM> for update-installation prior to checkout of new 

hardware/software 

Contents: monitor and data and program files used by the monitor 
in normal operation 

PS:<SUBSYS> 

or PS:<NEW-SUBSYS> 

Contents: all the system programs a user would normally wish to 
run 

If your installation chooses to locate files other than exactly as 
suggested in text and examples, it is your responsibility to correctly 
interpret procedures according to your installation's file-location 
scheme. To do this you must remember the structure and directory 
where files have been placed. 

Responses illustrated as part of the procedures are examples only. 

Because system files are system-dependent, the output you see may be 

different. For example, your site may not have four printers or a 
card reader. 

Figure 10-1 is a flowchart of the installation procedure. Step 
numbers on the chart correspond to step numbers in the text. 
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Log in and Enable with 
OPERATOR or WHEEL privileges. 



Step 1 




Step 8 



Step 9 



EditSYSJOB. RUN 

• include job to run FAL 

• include job to run NETCON 



Edit 4 -CONFIG.CMD 
Enter node name 
and node number 



Set up front end Software 

• nodename. SYS to< SUBSYS > 

• load files to < SUBSYS > 




( .To . >> 

V Verification / 



Step 2 



Set up DN200 Software 

• node name. SYS to< SUBSYS > 

• load files to< SUBSYS > 



EditSYSJOB. RUN 

• include job to run FAL 

• include job to run NETCON 




Step 3 



Include 
RUNSYS:CDRIVE 



Edit 4 -CONFIG.CMD 

Enter node name and number 

(central processor) 



Step 4 



Create NCP. CMD 

• Set up front end software 

• Enter commands 

• to LOAD front end 

• to SHOW QUEUE NCP - REQUESTS 




Step 5 



Step 6 



Create DN200. CMD 

Set up DN200 

software 



Edit PTYCON. ATO 
include TAKE NCP. CMD 




Step 7 



Edit PTYCON. ATO 
nclude TAKE DN200.CMD 



EditSYSTEM.CMD 

• start printer 

• start card reader 



( Tr_> ) 

V Verification J 



MR-S-358-79 



Figure 10-1 Installing DECnet-20 Software 
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When you are logged in and enabled with OPERATOR or WHEEL privileges: 

• To install a DECSYSTEM-2040/50/60 , perform Steps 1 through 7 

• To install a DECSYSTEM-2020 , perform Steps 8 and 9 only 

Step 1: Set up the DECnet software. 

If you have already executed any of the COPY commands listed below, do 
not repeat them. If you have not purchased the RJE option, do not 
give the DN200-related commands. 

For the communications front end: 

$COPY (FROM) PS:<DN20-l>nodename.SYS (TO) PS : <SUBSYS>nodename . SYS 

The nodename parameter is the same as the response you gave to 
the NETGEN command NODE NAME for the communications front end. 

$COPY (FROM) PS:<DNGEN>DTEMPS.BIN (TO) PS : <SUBSYS>DTEMPS . BIN 

$COPY (FROM) PS:<DNGEN>DTEMPT.BIN (TO) PS : <SUBSYS>DTEMPT . BIN 

For the DN200 remote station: 

$COPY PS:<DN200>nodename.SYS (TO) PS : <SUBSYS>nodename . SYS 

The nodename parameter is the same as the response you gave to 
the NETGEN command NODE NAME for the DN200. 

If you are installing more than one DN200, each nodename. SYS file 
must be copied from the appropriate directory to the <SUBSYS> 
directory. 

$COPY (FROM) PS:<DNGEN>SECDMC.SYS (TO) PS : <SUBSYS>SECDMC . SYS 

$COPY (FROM) PS:<DNGEN>TERDMC.SYS (TO) PS<SUBSYS>TERDMC . SYS 

Step 2: Edit SYSJOB.RUN. 

In Steps 2 through 7 you are editing SYSTEM files. Any errors, such 
as duplication of commands, must be avoided. When you have completed 
each edit, use the EDIT command P" : * to check the entire file. Or, if 
you prefer, use the TYPE command to check the file before you edit it 
and again after you edit it. 

Enter : 

$DEFINE EDITOR: SYS : EDIT . EXE GE) 

$CONNECT (TO DIRECTORY) PS : <SYSTEM>C^T) 

Gp 

$EDIT (FILE) SYSJOB.RUNQi 
The system responds: 

EDIT: SYS JOB. RUN. 1 
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Enter : 

*FJOB ( ESC )( RET ) 

The system responds: 

00800 JOB /LOG OPERATOR XX OPERATOR 
Enter : 

*F ( ESC ) ( RET ) 

The system responds: 

01600 JOB 1 \ LOG OPERATOR XX OPERATOR 
Enter : 

*F C ESC ) (_RET J 

Continue until the response is: 

%Search fails 

Enter : 

This command is to find the line number to insert for your entry. 
You must judge by the line number of the last JOB number. The 
line number will probably be different from the example. 

*pl60Q:* P^T ) 

The response will be the entire last JOB series. It will be similar 
to: 

01600 JOB 1 \LOG OPERATOR XX OPERATOR 

01700 ENA 

01800 MFORK 

01900 RUN SYS:ORION 

02000 RUN SYS:QUASAR 

m l nn PPM eye • r pmcpT /mamp .ri 

02200 RUN SYS:LPTSPL/NAME:L2 

02300 RUN SYS:LPTSPL/NAME:L3 

02400 RUN SYS:LPTSPL/NAME:L4 

02500 RUN SYS:CDRIVE 

02600 RUN SYS:BATCON 

02700 \ 

If you are entering at the end of the file, line numbers will appear 
automatically after you insert the first line; if you are not at the 
end, that is, there is at least one line following the last JOB 
series, use the command *I.!8. 
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If the last JOB series found is as shown above (lines 01600 to 02700), 
Enter : 

*i2800QFT) 

02800 JOB 2 \LOG OPERATOR XX OPERATOR (^FT ) 

02900 ENAQeD 

03000 RUN SYS:FALQFT) 

03100 \G*D 

03200 JOB 3 \LOG OPERATOR XX OPERATORQeT) 

03300 ENAQID 

03400 RUN SYSrNETCONQlD 

03500 \CHD 

03600 $ 



[SYSJOB.RUN.3] 
$ 



NOTE 



If your configuration is to include RJE 
(DN200) , check to ensure that there is a 
"RUN SYS:CDRIVE" command (if your remote 
station will have a card reader) . Check 
to ensure that there are as many "RUN 
SYS:LPTSPL" commands as there are total 
printers (host site and RJE station 
combined). If SYSJOB.RUN does not meet 
these requirements, edit the file to 
include the necessary statements. 



Step 3: Edit the 4-CONFIG.CMD. 
Enter : 



ESC 

$EDIT (FILE) 4-CONFIG.CMD (juT) 

The system responds: 

EDIT: 4-CONFIG.CMD. 9 
* 

Enter : 

*I*QeT) 

The system responds: 

18200 

(or whatever number follows the last line now in the file) 

Enter : 



18200 NODE nodename nodenumberQH 
18300 $ 



*EU C^P 
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Step 4: Create an NCP.CMD file. 
Entries and responses: 



$CREATE NCP.CMDQiD 

INPUT: NCP.CMD. 1 

00100 ENTER NCP f^D 

00200 SET EXECUTOR servername flip 

(servername is the node name for the host or 

central processor) 
00300 SET SECONDARY-LOAD-FILE DTE20 PDP-11 PS : <SUBSYS>DTEMPS .BINQID 
00400 SET TERTIARY-LOAD-FILE DTE20 PDP-11 PS : <SUB SYS> DTEMPT. BIN C^D 
00500 SET NODE nodename SERVER servername DTE20_lCHD 

(servername is the node name for the host, nodename in this 

and subsequent lines is the front-end node name) 
00600 SET NODE nodename LOAD-FILE PS : <SUBSYS>nodename . SYS CEgD 
00700 SET NODE nodename DUMP-FILE PS : <SUBSYS>nodename . DMPQiD 



00800 SET NODE nodename PROTOCOL-TYPE NETWORK-SERVICES-PROTOCOLU^ 

00900 LOAD NODE nodename C^O 

01000 SHOW QUEUE NCP-REQUESTSQiD 

01100 RETURN C^T) 

01200 $ 

*EUQID 

[NCP.CMD. 1] 
S 



NOTE 

The severname (host node name) that you 
use in the above commands must be 
identical to the name used in editing 
the 4-CONFIG.CMD file in Step 3. 

Step 5: Create a DN200.CMD file if your system includes a DN200 

Entries and responses: 

$CREATE DN200.CMDGEJ 

INPUT: DN200.CMD. 1 

00100 ENTER NCPQID 

00200 SET EXECUTOR server name Qi7 



NOTE 

The servername above is the node name of 
the host or central processor. 

00300 SET SECONDARY-LOAD-FILE DMC PDP-11 PS : <SUBSYS>SECDMC . SYSQIl 
00400 SET TERTIARY-LOAD-FILE DMC PDP-11 PS : <SUBSYS>TERDMC . SYS CUD 
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NOTE 

If more than one DN200 is in your 
configuration, repeat lines 500,600, and 
700 which follow. Give specific 
parameters for each DN200. 



00500 set node nodename SERVER servername KDP_0_2 



NOTE 

The servername above is the name of the 

DECnet communications front end. The 

controller number is the number of the 

front-end controller that controls the 

line to the DN200 (line 2 in the 

example) . The nodename in the above and 

all subsequent lines is the nodename of 
the DN200. 



00600 SET NODE nodename LOAD-FILE PS: <SUBSYS>nodename . SYSCsilJ 
00700 SET NODE nodename DUMP-FILE PS : <SUBSYS>nodename.DMP C^O 
00800 RETURN Q^T ) 
00900 $ 
*EU CiiT) 



Step 6: Edit PTYCON.ATO 

Entry and response: 

$EDIT PTYCON.ATO QID 
Edit: PTYCON.ATO. 5 
* 

Entry and response: 

*FTAKE SYSTEM: SYSTEM. CMDdD 
01100 TAKE SYSTEM:SYSTEM.CMD 
* 

Entry and response for DN20 without DN200: 

*I. UCnD 

01150 TAKE SYSTEM :NCP. CMP C^ 

*EUfIZ7 



Entry and response for DN20 with DN200: 



*I. I2C*iQ 

01120 TAKE SYSTEM :NCP.CMDQID 

01140 TAKE SYSTEM:DN200.CMDQeT) 

*EUC^T) 
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NOTE 

If your system does not include a DN200, 
you have completed the installation 
procedures. Go to Section 10.2. If 
your system does include a DN200, 
continue with Step 7. 

Step 7: Edit SYSTEM.CMD. 

Entry and response: 

$EDIT PS:<SYSTEM>SYSTEM.CMDGED 
Edit: SYSTEM.CMD 

Print the file using edit and locate a logical place to insert one or 
two commands. The edit procedures in the example given may need to be 
modified to fit the contents of your system's SYSTEM.CMD file. 

The commands to be added are: 

If the DN200 has a printer, enter: 

START PRINTER 0/NODE : DN200 : : 

If the DN200 has a card reader, enter: 

START READER 0/NODE : DN200 : : 

(The DN200:: given above represents the node name you specified 
for the DN200 at generation time.) 
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Example: 

$edit system.cmd C^O 
Edit: SYSTEM.CMD. 1 

*P" : * ( RET ) 

00100 MOUNT STRUCTURE SNARK: 

00 20 MOUNT STRUCTURE LANG: 

00300 MOUNT STRUCTURE MISC: 

00400 SET BATCH-STREAM TIME-LIMIT 5 

00500 SET BATCH-STREAM 1 TIME-LIMIT 10 

00600 SET BATCH-STREAM 2 TIME-LIMIT 11000 

00700 SET BATCH-STREAM 3 TIME-LIMIT 11000 

00800 SET BATCH-STREAM 3 PRIORITY-LIMITS 20:63 

00900 SET BATCH-STREAM 0:2 PRIORITY-LIMITS 1:19 

01000 START BATCH-STREAM 0:3 

01100 SET PRINTER PAGE-LIMIT 20000 

01200 SET PRINTER 1 PAGE-LIMIT 500 

01300 START PRINTER 0:1 

01400 START READER 

01500 DISABLE OUTPUT-DISPLAY ALL-MESSAGES /JOB 

*i.-l! 2(«D 

01420 START PRINTER 0/NODE :DN200 : :QeT) 

01440 TART READER 0/NODE : DN200 :: QjTT) 

*pl300:*CiD 

01300 START PRINTER 0:1 

01400 START READER 

01420 START PRINTER 0/NODE: DN200 : : 

01440 START READER 0/NODE : DN200 : : 

01500 DISABLE OUTPUT-DISPLAY ALL-MESSAGES /JOB 

*eu ( ret ) 

[SYSTEM.CMD. 2] 
$ 

You have completed DECSYSTEM-2040/50/60 installation. Continue with 
Section 10.2. 

Step 8: Edit SYSJOB.RUN (DECSYSTEM-2020) 

In Steps 8 and 9, you are editing system files. Any errors, such as 
duplication of commands, must be avoided. When you have completed 
each edit, use the EDIT command p~:* to check the entire file. Or, if 
you prefer, use the TYPE command to check the file before and after 
you edit it. 

Enter : 

$DEFINE EDITOR: SYS : EDIT. EXE GEO 

$CONNECT (TO DIRECTORY) PS : <SYSTEM> QlD 

GEO 

$EDIT (FILE) SYS JOB. RUN GUD 

The system responds: 

EDIT: SYSJOB.RUN. 1 
* 
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Enter : 

*FJOBQiDGDD 

The system responds: 

00800 JOB /LOG OPERATOR XX OPERATOR 
Enter: 

*F ( ESC )( RET ) 

Continue until the response is: 

%Search fails 

Enter : 

This command is to find the line number to insert for your entry. 
You must judge by the line number of the last JOB number. It 
will probably be different from the example. 

*p800:*CED 

The response will be the entire last JOB series. It will be similar 
to: 

00800 JOB 1 /LOG OPERATOR XX OPERATOR 

00900 ENA 

01000 ~ESET LOGIN PSEUDO 

01100 ~ESET LOGIN CONSOLE 

01200 ~ESET OPERATOR 

01300 PTYCON 

01400 GET SYSTEM: PTYCON. ATO 

01500 / 

If you are entering at the end of the file, line numbers will appear 
automatically after you insert the first line; if you are not at the 
end, that is, there is at least one line following the last JOB 
series, use the command *I.!8. 

NOTE 

Do NOT enter either of the jobs below if 
they have already been entered. 

If the last JOB series found is as shown above (lines 00800 to 01500) , 
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Enter : 

*il600QJT) 

01600 JOB 2 \LOG OPERATOR XX OPERATOPQiD 

01700 ENAGID 

01800 RUN SYS:FAL r^T ) 

01900 \C£T) 

02000 JOB 3 \LOG OPERATOR XX OPERATORQiD 

02100 ENAQI7) 

02200 RUN SYSrNETCONQiD 

02300 xcud 

02400 $ 

*EUf^P) 

[SYSJOB.RUN.3] 

$ 

Step 9: Edit the 4-CONFIG.CMD (DECSYSTEM-2020) 
Enter : 



ESC 

T 

$EDIT (FILE) 4-CONFIG.CMD Lel) 

The system responds: 

EDIT: 4-CONFIG.CMD. 9 
* 

Enter: 

* I* ( RET ) 

The system responds: 

18200 

(or whatever number follows the last line now in the file) 

Enter : 

18200 NODE nodename nodenumber ( ret ) 

This is the node name and node number (decimal) of the host or central 
processor . 

18300 $ 
*EUQe7) 



10.2 INSTALLATION VERIFICATION PROCEDURE 

The DECnet-20 installation verification procedure ensures that the 
appropriate DECnet-20 software modules have been installed. The 
verification procedure includes: 

• Checking for the existence of each required software module 

• Checking for the correct version of each required software 
module 
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The verification tests are run under the User Environmental Test 
Package (UETP) . Before you begin the verification procedures, you 
must satisfy the requirements of UETP. 

Examine your login-directory. The directory to which you login must 
include the following two entries: 

IPCF 

USER GROUPS nnnn,100 

The nnnn represents your assigned user group for normal activity. The 
100 that follows is required by UETP. Use the TOPS-20 command BUILD 
to add the two required subcommands. 

Figure 10-2 is a flowchart of the verification procedure. Step 
numbers on the chart correspond to step numbers in the text. 
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Log in with 

OPERATOR or WHEEL 
privileges enabled. 



Step 1 



Redefine the logical 
name DSK: to include 

< UETP. LIB > and 

< SUBSYS > 



Steps 2-3 



Connect to < UETP. RUN > 
and delete all files. 



Steps 4-5 ^k. 






S^ DECSYSTEM 


^\2020 


Enable 

VF2020 

for Step 6. 




>0/60 


O 




[2040/S 


'NETVFY 
Completed 
? 

jNO 




Enable 
NETVFY 
for Step 6. 






I 




n. YES 








^-RJE\ 
option and ^s»" ^S 




Enable 
RJEVFY 
for Step 6. 




^^^ yet run . 






NO 










Step 6 










Run test 
•NETVFYor 

• VF2020 or 

• RJEVFY 







Step 7 



Step 8 






Exit from 
UETP. 




Step 9 








Stop and reload 
the system. 






{ To \ 
1 Certification 1 
V Procedure J 
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Figure 10-2 Verifying the DECnet-20 Software 
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Go to Step 1 when you are logged in with OPERATOR or WHEEL privileges 
enabled. 

Step 1: Redefine the logical name DSK:. 

Redefine the logical name DSK: to include the directories <UETP.LIB> 
and <SUBSYS> as part of the file search sequence. To verify the 
execution of the command, use the INFORMATION LOGICAL-NAME command. 

Enter : 

dp 

$DEFINE (LOGICAL NAME) DSK: DSK : , <UETP . LIB> , <SUBSYS>G»D 

Gp 

$ INFORMATION (ABOUT) LOGICAL-NAMES C^O 

The system responds: 

DSK: => DSK: , <UETP.LIB>, <SUBSYS> 
$ 

Step 2: Connect to directory <UETP.RUN>. 
Enter : 

$CONNECT (TO DIRECTORY) <UETP . RUN> C^D 

Step 3: Ensure that <UETP.RUN> is empty. 

Enter : 

QsT) 

$DELETE (FILES) * . * . * f^T) 

The system responds: 

filenamel [OK] 
filename2 [OK] 



$ 
(if files were found and deleted) 

or : 

%NO FILES MATCH THIS SPECIFICATION- *.*.* 
$ 
(if the directory was empty) . 
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Step 4: RUN the UETP program. 

Enter : 

$RUN UETP QID 

The system responds: 

[da-mon-yr hh:mm:ss USER ENVIRONMENT TEST PACKAGE] 
UETP> 

Step 5: Enable the DECnet-20 verification test. 

Enter : 



Gp 



UETP>ENABLE (TEST) prgnam C^D 

where: 

prgnam = NETVFY for a DECSYSTEM-2040/50/60 

= VF2020 for a DECSYSTEM-2020 

= RJEVFY for DECSYSTEM 2040/50/60 with optional addition 
of remote station DN200 



NOTE 

If you are validating RJE, NETVFY must 
perform successfully before you run 
RJEVFY. 



The system responds: 

hh:mm:ss [ENABLE COMPLETED] 
UETP> 

Step 6: Begin the verification procedure. 

The system confirms the BEGIN command and displays the messages shown 
below as verification progresses. 

Enter: 

UETP>BEGINGeT) 

The system responds: 

hh:mm:ss [BEGIN COMPLETED] 
UETP> 

START prgnam da-mon-yr hh:mm:ss message 
MAJOR prgnam da-mon-yr hh:mm:ss message 
END prgnam da-mon-yr hh:mm:ss message 

(prgnam is the name of the file enabled in Step 5.) 

You may check the status of UETP at any time. Use the procedure shown 
in Step 7. 
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Step 7: Check status of verification procedure. 
Enter : 

STATUS C^rr) 
The system may respond: 

[da-mon-yr hh:mm:ss] 

TEST NAME STATUS TIMES TO TIMES ERROR START 
(FILE NAME) BE RUN RUN COUNT TIME 



prgnam.SUP queued 10 da-mon-yr hh:mm:ss 
UETP> 

The status QUEUED means that the verification process is waiting to be 
run. STATUS may also be given as RUNNING or ENDED. This status 
output will be given automatically when status is ENDED. When ENDED 
is displayed, continue with Step 8. If errors occur, refer to Section 
10.2.1. 

Step 8: Exit from UETP 
Entry and response: 

( ESC ) 

EXIT (TO MONITOR) L^L) 
$ 

Step 9: Stop and reload the system if test completed successfully. 

Now that you have restored all the DECnet-20 software to the proper 
directories, modified the appropriate command files, and verified the 
software, you must first stop the system and reload it to activate 
DECnet-20. 

Enter : 

$ (ctrla) (does not echo) 

The system responds: 

PAR> (for DECSYSTEM 2040/50/60) 
KS10> (for DECSYSTEM-2020) 

Enter : 

sh ( ret ) 
The system shuts down with appropriate messages. 
To reload the DECSYSTEM-2040/50/60: 

Press the ENABLE and DISK switches simultaneously. 
To reload the DECSYSTEM-2020: 

Press the BOOT switch. 
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After the system completes printing loading and configuration 
messages, the system displays ENTER CURRENT DATE AND TIME:. 

Enter: 

day-mon-yr hhmm (followed by carriage return) 

The system repeats the date and time you have entered and asks for 
confirmation. Answer with Y or N, and repeat if necessary. 

The system then asks WHY RELOAD? 

Type an abbreviation that indicates the reason for the reload, 
for example, CTF for certification. The answer you type here is 
stored in the system error file and reported by SYSERR. (If your 
site has a code or standard abbreviation, use the appropriate 
entry. ) 

The system asks: 

RUN CHECKD? 

Enter : 

NQeT) 

The system now executes all the command files that load and start the 
various system tasks. These will now include the DECnet-20 tasks. 



10.2.1 Verification Procedure Messages 

Verification tests pass confirmation, event, and error messages to the 
UETP program. The various UETP elements route these messages to one 
or more of the following: 

• your terminal 

• the file RUN. LOG 

• the file EXCEPT.LOG 

In addition, batch generates a Batch Log file for each test run under 
UETP. This file is named prgnam.LOG, where prgnam is the name of the 
DECnet-20 verification test. This log file is appended to the file 
prgnam. ERL if a test reports an error to UETP via the SENDER program. 

Thus, if any test does not complete successfully, there are, in 
addition to the messages output to your terminal, three files that may 
be used to discover the problem. The table that follows summarizes 
message types and their destinations. 
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Table 10-1 
SENDER Message Types and Destinations 



MESSAGE 


DESTINATION 








TYPE 


TERMINAL 


EXCEPT.LOG RUN. LOG 


prgnam.ERL 


START 


yes 


no yes 


no 


MAJOR 


yes 


no yes 


no 


MINOR 


no 


no yes 


no 


ERROR 


yes 


yes yes 


yes 


END 


yes 


yes yes 


no 


LOG 


no 


no yes 


no 



If a test executes successfully, the following messages will be sent 
to your terminal in the order given: 

START prgnam date time Start of verification 

MAJOR prgnam date time Verifying f ile : <UETP.LIB>DECNET. VFY 

END prgnam date time End of verification 

If errors occur, one or more of the following will be sent to your 
terminal : 

ERROR prgnam date time VERIFY program not available 

The program VERIFY.EXE could not be found. This program is 
required to perform the verification. If you have made no 
errors, this probably indicates an error in the TOPS-20 
installation procedures. YOU CANNOT CONTINUE UNTIL THE VERIFY 
PROGRAM IS IN <SUBSYS> or <NEW-SUBSYS> . 

ERROR prgnam date time DECNET.VFY file (input to the VERIFY program) 
is not available. 

This probably indicates an error in your DECnet installation 
procedures. YOU CANNOT CONTINUE UNTIL DECNET.VFY IS IN 
<UETP.LIB>. 

ERROR prgnam date time ERRORS running VERIFY program 

One or more files did not verify correctly. Either a required 
file is not present, a required file is in the wrong directory, 
or the data is incorrect (determined by noting that the file's 
checksum is different from that of the file shipped by DIGITAL) . 
Return to the DECnet installation procedure and correctly restore 
the files that did not verify. if the files are not available, 
notify your DIGITAL Software Specialist. 

ERROR prgnam date time Verification procedure exceeded CPU time limit 

This message indicates a problem with the verification procedure 
itself. Notify the DIGITAL Software Specialist. 

ERROR prgnam date time Unknown error in VERIFY test 

This message indicates conditions for which no specific check 
could be made. Consult the DIGITAL Software Specialist. 
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10.3 INSTALLATION CERTIFICATION PROCEDURE 

You have now determined that the correct version of each required 
DECnet-20 software module has been installed. In the certification 
procedures you will ensure that the various components of your 
DECnet-20 system function at a basic, minimal level. The verification 
and certification procedures are sometimes referred to as "acceptance 
tests". Together they confirm the acceptability of the installed 
hardware and software to the extent successfully tested. 

The certification tests to be run include: 

1. Local-NCP test 

2. Line-loopback test 

3. Remote-NCP test 

4. Remote node file transfer test 

5. DN200 test 

6. Error and event logging test 

The line-loopback test and the remote node file transfer test are run 
as batch jobs under UETP. For these two tests both general procedures 
and error messages are the same as for the verification procedures you 
have completed. The other four tests are run in production mode. 
That is, you type commands to a program or you tell the program to 
take the commands from a command file you create. 

All files associated with installation verification and certification 
of DECnet-20 Version 2 are in one of two directories, as follows: 

Directories and files for DECSYSTEM-2040/50/60 certification (and 
verification) : 

PS:<UETP.LIB> 
CHARS.TXT 
DECNET.DAT 
DNV2FT.APP 
DNV2LN.CMP 
DYNETS.EXE 
NETVFY.VER 
NULL. TXT 
PICTUR.TXT 
RJEVFY.VER 

PS:<UETP.DECNET> 
BRIEF.TXT 
DETAIL.TXT 
LOCAL-NCP.CMD 
LOCAL-NCP-KL-EXAMPLE . CMD 

.TXT 
REMOTE-NCP.CMD 
REMOTE-NCP-20-EXAMPLE.CMD 

.TXT 
REMOTE-NCP-DN20-EXAMPLE.CMD 

.TXT 
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Directories and files for DECSYSTEM-2020 certification (and 
verification) : 

PS:<UETP.LIB> 
DECNET.DAT 
DNV2FT.APP 
DNV2LL.CMP 
DNWAIT.EXE 
DYNETS.EXE 
NULL. TXT 
TESTT2.CMP 
VF2020.VER 

PS:<UETP.DECNET> 
BRIEF.TXT 
DETAIL.TXT 
LOCAL-NCP.CMD 
LOCAL-NCP-KS-EXAMPLE . CMD 

.TXT 
REMOTE-NCP.CMD 
REMOTE-NCP-20-EXAMPLE.CMD 

.TXT 

Note that the <UETP.LIB> directory contains all control files, command 
files to be edited to match your configuration, and original test data 
files= You will create several files to add to PS: <UETP. LIB> as you 
perform the various tests. These are the files that must be kept. 
They will be needed to repeat certification procedures if new 
DECnet-20 hardware/software is brought on line. They will be helpful 
in constructing user application tests to test production programs 
that normally run under batch. (For additional information on 
constructing your own tests, refer to the TOPS-20 User Environment 
Test Package Procedures/Reference Manual.) 

The files on the <UETP.DECNET> directory contain sample command files 
and sample output files. They serve to help you understand what to do 
and how to do it. They may be saved or deleted, according to your 
needs, after the certification completes successfully. 

Before you begin certification testing you must: 

• Have a suitable loopback connector for each line to be tested 
(later you will be told at what point to install it) 

• Create certain files to establish values specific to your 
configuration 



10.3.1 Loopback Connector 

In order to run the certification procedure for DECnet-20 without 
requiring another DECnet node to talk to, it is necessary to use some 
form of echoing device. A device known as a loopback connector may be 
attached to the line interface in place of the modem. All data 
directed to the line will then be echoed back to the sender. 



10-21 



INSTALLING DECnet-20 

Loopback connectors come in various models. DECSYSTEM-20s with 
communications hardware are supplied with the model loopback connector 
that is suitable for the particular communications device being used. 
Loopback connectors should be installed by DIGITAL Software Service or 
Field Service representatives. To test all DECnet lines in one run 
(the line loopback test) , you will need one connector for each line to 
be tested. 

Several of the acceptance tests may be run by either direct terminal 

input or by using a command file; some tests are run under UETP while 

others are not. There are also system dependencies. Use the 

flowcharts (Figure 10-3) as an overview and checklist as you perform 
the tests. (Connectors may span pages.) 
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Local -NCP Test (Section 10.3.2) 



Step 1A: Direct Terminal Input 

and/or 
Step IB: Command File Input 




DECSYSTEM 



2020 



Step 2A: Direct Terminal Input 

and/or 
Step 2B: Command File Input 



Line Loopback Test (Section 10.3.3) 
Step 1 i 

I Log in with OPERATOR or WHEEL privileges enabled. I 



Step 2 



Establish the search list. 



Step 3 



Create file for DN20 node name. 



Step 4 




Create file PS:<UETP. LIB~> DNV2LN. LIN 



Step 5 



Ensure that PS: < UETP. RUN > is empty. 



Steps 6-7 



Run UETP. Enable test and begin testing. 



Step 8 



Respond to OPR messages: 

Turn line off, install connector, turn line on, 

wait for test to be completed, turn line off. 



Step 9 



Check RUN. LOG 



Step 10 



' • Remove connectors 

• Reconnect system 
normally 

• Reload front end 

• Log in with OPERATOR 
or WHEEL privileges 




' 'Remove connectors 

• Reconnect system 
normally 

• Reload system 

• Log in with OPERATOR 
or WHEEL privileges 



Step 11 



Turn all lines off. 



Step 12 



Install loopback connector on line to be 
tested. 



Step 13 



Enable loopback and start line for cable 
loopback. 



Step 14 



Ensure that PS: < UETP. RUN> is empty. 



Steps 15 - 16 



Run UETP. Enable test and begin testing. 



Step 17 



Examine UETP output. 




Continue to 
end of procedure 
then repeat 
test. 



Abort TEST72 and 
exit from UETP 



Step 19 



Check RUN. LOG 



Step 20 



yS^ test ^ s n. s' were ^vmq 
completed ^^ yS^ tests enabled 
successfully ^r ^s. and begun ^S 
\. ? -^ ^S. ? s' 


Repeat test 
from Step 1. 








YES 






Step 21 
















Disable loopback 
testing for 
the line. 






Repeat test 
from Step 14. 


























MR-S-356-79 



Figure 10-3 Certifying the DECnet-20 Software 
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Remote - NCP Test (Section 10.3.4) 





2040/50/60 , 


^ DECSYSTEM ^ 


2020 












Step 1A: Direct Terminal Input 

and/or 
Step 1B: Command File Input 


Step 2A: Direct Terminal Input 

and/or 
Step 2B: Command File Input 











Remote and Local Network File Transfer Test (Section 10.3.5) 
Step 1 1 



Log in as a non - privileged user. 



Step 2 



Create an NFT. INIT file in 
PS:< UETP. LIB > 



Step 3 



Check availability of nodes to be 
tested 



Step 4 



Define file search association of DSK: 



Step 5 



Ensure that PS: < UETP. RUN > is empty. 



Step 6 



Run UETP. Enable test and 
begin testing. 




Check directory for 
IPCF and USER GROUP 
100, and check 
define statements. 



Repeat from 
Step 3 or from 
point in 
DNV2FT. LOG 
where error 
occurred. 




®- 
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Figure 10-3 (Cont.) Certifying the DECnet-20 Software 
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DN200 Tests (Section 10.3.6) 

Step 1 r 



Check DN200 status and queue 
status at operator's console. 



Step 2 



Print file on local and DN200 
printers and compare. 




Step 3 



Contact 
your 
Software 
Specialist. 



Prepare card deck for submission 
to ON200 card reader. 



Step 4 



Read card deck on DN200 
card reader. 




Examine the 
card deck 
for error and 
correct the 

error. 



Contact your 
Software 
Specialist re: 
skewed output. 



DECnet Error and Event Logging Test (Section 10.3.7) 

r 
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Figure 10-3 (Cont.) Certifying the DECnet-20 Software 
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10.3.2 Local-NCP Test 

The commands to be executed for the LOCAL-NCP test may be typed 
directly at your terminal or entered by typing a TAKE command to NCP 
via OPR. 

If your host node is a DECSYSTEM-2040/50/60, go to Step 1A if you wish 
to use direct input to your terminal; go to Step IB if you wish to 
use a command file. 

If your host node is a DECSYSTEM-2020, go to Step 2A if you wish to 
use direct input to your terminal; go to Step 2B if you wish to use a 
command file. 

Step 1A. Local-NCP test using direct terminal input 
(DECSYSTEM- 2040/50/ 60) 



Enter : 



CUD 

@enaBLE (CAPABILITIES) fi^O 

$type ps : <uetp.decnet>local-ncp-kl-example . cmdC^T 



Read the example file. Refer to the seven commands below the second 
line of asterisks. To test YOUR local NCP, certain changes are 
required : 

The first command will be: 

SET EXECUTOR your local host name 

You entered the node name of your central processor in the 
4-CONFIG.CMD file in Step 3 of the Installation Procedures 
(Section 10.1). The node name in the SET EXECUTOR command 
must agree with the node name in the 4-CONFIG.CMD file. 

The SHOW STATUS LINE lineid command (s) must also be changed to 
reflect your configuration. You include the line identification 
of each DTE20 to be tested. 

Follow the directions given in the example-file. Type the commands/ 
making the changes indicated. If you wish to see what the output 
should look like, enable and type the file 
PS:<UETP.DECNET>LOCAL-NCP-EXAMPLE.TXT. This example is the result of 
a TAKE command and includes a list of outstanding NCP requests in 
response to the SHOW QUEUE NCP-REQUESTS command. If you "enter the 
commands directly, you may not receive this list because your typing 
speed is slower than the response speed. An example of direct entry 
and response appears below. Your typed input will differ in the SET 
EXECUTOR and SHOW STATUS LINE commands. 
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Example of direct entry and response: 



Gp 



^ENABLE (CAPABILITIES ) fJ£T) 
SOPRC^H 

r T 

OPR>DISABLE outPUT-DISPLAY (of) all-MESSAGES Q^O 

OPR> 

12:56:17 — OUTPUT DISPLAY for OPR Modified — 

OPR>enter ncpQID 

GiD 
I 



NCP>set exeCUTOR 2102GID 



NCP>show exeCUTORC^D 

NCP> 

12:56:49 Current EXECUTOR is node 2102 

NCP>show status loCALCHfD 

NCP> 

12:57:10 NCP request # 2 [SHOW STATUS LOCAL] 

Status of local node as of 16-Jul-79 12:57:10 

Node Name is 2102, # 64, System = 2102 Development System, 
TOPS-20 Routing Version = 3.0.0, Communications Version = 3.0.0 
State is On, Default Host = Unknown 

Function completed successfully 

( ESC ) ( ESC ) ( ESC ) 



NCP>show STATUS knoWN liNESGiD 

NCP> 

12:57:54 NCP request # 3 [SHOW STATUS KNOWN LINES] 

Status as of 16-Jul-79 12:57:54 

Line ID State Adjacent Node 

DTE20_0_0_0 OFF 

DTE20_1_0_0 On DN20A 

DTE20_2_0_0 Off 

DTE20_3_0_0 Off 

Function completed successfully 
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GED c Est ) ( esc ) 
\ \ I , v 

NCP>shOW stATUS liNE DTE20_lQID 

NCP> 

12:58:41 NCP request # 4 [SHOW STATUS LINE DTE20 _ 1] 

Status as of 16-Jul-79 12:58:41 

Line ID State Adjacent Node 

DTE20_1_0_0 On DN20A 

Function completed successfully 



ESC ) ( ESC ) ( ESC ) 

NCP>shOW STATUS liNE dte20_2(_5£lJ 



NCP> 

12:59:20 NCP request # 5 [SHOW STATUS LINE DTE20 _ 2] 

Status as of 16-Jul-79 12:59:20 

Line ID State Adjacent Node 

DTE20_2_0_0 Off 

Function completed successfully 



( £ sc ) 

1 I , x 

NCP>show qUEUE (OF) ncP-REQUESTSC_5!lJ 

NCP> 

12:59:52 

There are no outstanding NCP requests. 

NCP>exitQrT) 



$disaBLE (CAPABILITIES)^ 



If you wish to repeat the LOCAL-NCP test using a command file, go to 
Step IB; otherwise go to Section 10.3.3. 

Step IB. Local-NCP test using a .CMD file (DECSYSTEM-2040/50/60) 

The file LOCAL-NCP.CMD in the directory PS: <UETP.DECNET> contains the 
commands to test the local NCP. One SET EXECUTOR command and two SHOW 
STATUS LINE commands are given with dummy arguments. These dummy 
arguments must be edited to reflect the node name and line 
identifications of YOUR configuration. The number of SHOW STATUS LINE 
commands must equal the number of DTE20 lines you wish to test. All 
lines you plan to* use for network traffic should be tested. The host 
or central processor node name in the SET EXECUTOR command must be 
identical to the name you entered in the 4-CONFIG.CMD file in Section 
10.1. 

The edited, file should be output to PS: <UETP.LIB> as shown in the 
example. Use the EDIT command EU to remove line numbers when you exit 
from EDIT. Including the host node name in the output file name will 
help identify it for future use. 
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Example entries and responses: 



@ENA GlD 

$CONN PS:<UETP.DECNET>C^~Q 

Gp 

$edit local-ncp.cmd. 4 (OUTPUT AS) PS : <UETP. LIB>LOCAL-NCP-2102 .CMDQID 

Edit: LOCAL-NCP.CMD. 4 

*p* : * (~*" ) 

00100 

00200 

00300 

00400 

00500 

00600 

00700 

00800 

00900 

01000 

01100 

01200 

01300 

01400 

01500 

01600 

01700 

01800 

01900 

02000 

02100 

02200 

02300 

02400 

02500 



02600 

02700 

02800 

02900 

03000 

03100 

03200 

03300 

03400 

*shost 

02800 

*sline 

03200 

*sline 

03300 

*p2800 

02800 

02900 

03000 

03100 

03200 

03300 

03400 

*eu(jjFT) 



******************************************************************* 

THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY ONLY BE USED 
OR COPIED IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE. 

COPYRIGHT (C) 1978,1979 BY DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS 

DECnet-20 V2 Local NCP test 

To run this test start OPR in a job enabled with wheel or operator 
privileges and enter the NCP command subset: 

@ENABLE 
$OPR 

OPR>ENTER NCP 
NCP> 

Then either enter: 

NCP>TAKE REMOTE-NCP.CMD 

to execute the statements in the command file or 
type the following commands by hand. 

*********************************************************************** 



SET EXECUTOR host-node-name 
SHOW EXECUTOR 
SHOW STATUS LOCAL 
SHOW STATUS KNOWN LINE 
SHOW STATUS LINE line 
SHOW STATUS LINE line 
SHOW QUEUE NCP-REQUESTS 

-node -name $2102$280 O C^O 
SET EXECUTOR 2102 

$DTE 20_0$3200,EQiD 

SHOW STATUS LINE DTE20_0 

$DTE 20_l$3300,EQiD 

SHOW STATUS LINE DTE20_1 

:3400Q£D 

SET EXECUTOR 2102 
SHOW EXECUTOR 
SHOW STATUS LOCAL 
SHOW STATUS KNOWN LINE 
SHOW STATUS LINE DTE20_0 
SHOW STATUS LINE DTE20_1 
SHOW QUEUE NCP-REQUESTS 



[<UETP.LIB>LOCAL-NCP-2102.CMD.l] 
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When you have exited from EDIT, 

Enter: 

CONN PS: <UETP.LIB>QeD 

SOPR C^D 

OPR> ENTER NCP C^D 

NCP>TAKE LOCAL-NCP-xxxx.CMD QeT) 

where xxxx is the node name of the local host 

OUTPUT FOLLOWS 

Enter: 



NCP>EXITQiD 

Check your output as the test is being performed. No error messages 
should be printed. The output should have the same format as the file 
LOCAL-NCP-KL-EXAMPLE.TXT in PS : <UETP.DECNET> . This example is for a 
DECSYSTEM-2060 node with the node name 2102. Type the example file to 
compare it with your output. The output from your .CMD file should be 
similar in format to the example typed. Node names and line 
identifications may differ. 

When the test completes successfully, go to Section 10.3.3. 

Step 2A. Local-NCP test using direct terminal input (DECSYSTEM-2020) 
Enter: 

I 



@enaBLE (CAPABILITIES) dD 

$ type ps: < ue t p. decnet>l oca 1-ncp-ks -example .cmdCEi 

Read the example file. Refer to the seven commands below the 
second line of asterisks. To test YOUR local NCP, certain 
changes are required: 

The first command will be: 

SET EXECUTOR your local host name 

The node name in the SET EXECUTOR command must agree with 
the node name in the 4-CONFIG.CMD file in PS:<SYSTEM>. 

The SHOW STATUS LINE lineid command (s) must also be changed to 
reflect your configuration. You include the line identification 
of each DECnet-20 line to be tested. For one line, your lineid 
will be KDP_0_0. For two lines, the lineids will be KDP_0_0 and 
KDP_0_1. 
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Now, type the commands (six or seven commands depending on the number 
of lines) shown in the example, making the changes indicated for node 
name and lineids. Check the output as the commands are being 
performed. There should be no error messages. When the response to 
the last command is complete, type EXIT following the NCP prompt. 
Compare your output with that of the example given below. The name of 
the 2020 node in the example is 4097. The 4097 has two DECnet-20 
lines. The DISABLE OUTPUT-DISPLAY command in the example is needed 
only if you are testing under timesharing. If you fail to give this 
command, messages from OPR such as the one shown before the DISABLE 
OUTPUT-DISPLAY command was executed will be scattered throughout the 
responses to your commands. 

Example: 

@ENAQeD 

$opr Chl) 

OPR>disable output-display all messages ( ret ) 

OPR> 

10:53:37 — MTA2 : Volume DAVESS, ANSI labeled tape mounted- 

OPR> 

10:53:42 — OUTPUT DISPLAY for OPR Modified — 

OPR>enter ncp ( «et ) 

NCP>set executor 4097 ( «t ) 

NCP>show executor ( ret ) 

NCP> 

10:54:42 Current EXECUTOR is node 4097 

NCP>show status known lines C^T) 

NCP> 

10:55:10 NCP request # 8 [SHOW STATUS KNOWN LINES] 

Status as of 18-Jul-79 10:55:10 

Line ID State Adjacent Node 

KDP_0_0_0 On 2102 

KDP_0_1_0 On 

Function completed successfully 

NCP^show status line kd° o o c ret ^ 

NCP> 

10:55:56 NCP request # 9 [SHOW STATUS LINE KDP _ _ 0] 

Status as of 18-Jul-79 10:55:56 

Line ID State Adjacent Node 

KDP_0_0_0 On 2102 

Function completed successfully 
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NCP>show status line kdp_0_lC«D 

NCP> 

10:56:44 NCP request # 10 [SHOW STATUS LINE KDP _ 0_ 1] 

Status as of 18-Jul-79 10:56:43 

Line ID State Adjacent Node 

KDP_0_1_0 On 

Function completed successfully 

NCP>show counts line kdp_0_0 ( ret ) 

NCP> 

10:57:47 NCP request # 11 [SHOW COUNTS LINE KDP _ _ 0] 

Counts for line KDP_0_0_0, as of 18-Jul-79 10:57:47 

Seconds since zeroed 27321 

Blocks received 11493 

Received line errors 

Blocks sent 13158 

Retran, line errors 

Retran, not line erros 

Resource errors 1 

Function completed successfully 



NCP>show counts line kdp_0_l(jEL) 

NCP> 

10:58:29 NCP request # 12 [SHOW COUNTS LINE KDP _ _ 1] 

Counts for line KDP_0_1_0, as of 18-Jul-79 10:58:29 

Seconds since zeroed 27361 

Blocks received 

Received line errors 

Blocks sent 

Retran, line errors 

Retran, not line errors 

Resource errors 

Function completed successfully 

NCP>show queue ncp-requests ( ret ) 

NCP> 

10:59:13 

There are no outstanding NCP requests. 

NCP>exitQir) 
$ 

If you wish to repeat the LOCAL-NCP test using a command file, go 
to Step 2B; otherwise go to Section 10.3.3. 
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Step 2B. Local-NCP test using a .CMD file (DECSYSTEM-2020) 



The file LOCAL-NCP.CMD in the d 
the commands to test the local 
two SHOW STATUS LINE commands a 
These dummy arguments must be e 
line identifications of YOUR co 
STATUS LINE commands must equa 
to test. All lines you plan to 
tested. The host or centra 
EXECUTOR command must be ident 
4-CONFIG.CMD file. 



irectory PS: <UETP.DECNET> contains 
NCP. One SET EXECUTOR command and 
re given with dummy arguments, 
dited to reflect the node name and 
nfiguration. The number of SHOW 
1 the number of KDP lines you wish 
use for network traffic should be 
1 processor node name in the SET 
ical to the node name in the 



The edited file should be output to PS: <UETP.LIB> as shown in the 
example. Use the EDIT command EU to remove line numbers when you 
exit from EDIT. Including the host node name in the output file 
name will help identify it for future use. In the example below, 
the node name is 4097. There are two DECnet-20 lines. You 
substitute the parameters that are correct for your node. In 
editing the command SHOW STATUS LINE line, be sure to include the 
",E" as shown in the example. If you fail to do this, the lineid 
will be substituted two times. 

Example entries and responses: 

f3ENAQ<rr> _ 

$CONN PS:<UETP.DECNET>(jiiD 



$EDIT 

Edit: 

*p~:*( 

00100 

00200 

00300 

00400 

00500 

00600 

00700 

00800 

00900 

01000 

01100 

01200 

01300 

01400 

01500 

01600 

01700 

01800 

01900 

02000 

02100 

02200 

02300 

02400 

02500 

02600 

02700 



LOCAL-NCP.CMD. 4 (OUTPUT AS) Fb : < Util'P . L1B> LOCAL-NCP- 4 9 7 . CMD C *" ) 
LOCAL-NCP.CMD. 4 

Kt[) 

*********************************************************************** 



THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY ONLY BE USED 
OR COPIED IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE. 

COPYRIGHT (C) 1978,1979 BY DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS 

DECnet-20 V2 Local NCP test 

To run this test start OPR in a job enabled with wheel or operator 
privileges and enter the NCP command subset: 

@ENABLE 
$OPR 

OPR>ENTER NCP 
NCP> 

Then either enter: 

NCP>TAKE LOCAL-NCP.CMD 

to execute the statements in the command file or 
type the following commands by hand. 

*********************************************************************** 
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02800 SET EXECUTOR host-node-name 

02900 SHOW EXECUTOR 

03000 SHOW STATUS LOCAL 

03100 SHOW STATUS KNOWN LINE 

03200 SHOW STATUS LINE line 

03300 SHOW STATUS LINE line 

03400 SHOW QUEUE NCP-REQUESTS 
*shos t -node -name $ 409 7 $28 00QeT) 

02800 SET EXECUTOR 4097 

*sline$KDP_0_0$32 0,EQET) 

03200 SHOW STATUS LINE KDP_0_0 

*sline$KDP_0_l$3300,EGID 

03300 SHOW STATUS LINE KDP_0_1 

*p2800:3400QED 

02800 SET EXECUTOR 4097 

02900 SHOW EXECUTOR 

03000 SHOW STATUS LOCAL 

03100 SHOW STATUS KNOWN LINE 

03200 SHOW STATUS LINE KDP_0_0 

03300 SHOW STATUS LINE KDP_0_1 

03400 SHOW QUEUE NCP-REQUESTS 

*eu (~*"~) 

[<UETP.LIB>LOCAL-NCP-4 097.CMD.l] 
$ 



When you have exited from EDIT, 
Enter: 



$CONN PS;<UETP.LIB>Qet 

$OPRQID 

OPR>ENTER NCPCUD 



NCP>TAKE LOCAL-NCP-xxxx.CMDQeT) 

where xxxx is the node name of the local host 
OUTPUT FOLLOWS 
Enter : 

ncp>exitGED 

To compare the output from your command file with an example, enable 
and type the file PS: <UETP.DECNET>LOCAL-NCP-KS-EXAMPLE.TXT. This 
example is the result of a TAKE command and includes a list of 
outstanding NCP requests in response to the SHOW QUEUE NCP-REQUESTS 
command. When you enter the commands directly, you may not receive 
this list because your typing speed is slower than the response speed. 

The output from your .CMD file should be similar in format to the 
example typed. Node names and line identifications may differ. There 
should be no error messages. When the test completes successfully, 
continue with the next section. 
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10.3.3 Line Loopback Test 

You have now tested that NCP commands function on the local node. 
Before you test NCP commands to a remote node, the line loopback test 
is performed to ensure that the line(s) from your node out to the end 
of the cable are functioning. 

Step 1: Log in and enable. 

Log in as a user with WHEEL or OPERATOR privileges enabled. This test 
is run under UETP. Therefore, use the directory to which you added 
the IPCF and USER GROUPS 100 subcommands. You should now be familiar 
with the UETP responses. Only the entries are given for this test. 
If you need to review the UETP output, refer to Step 7 in Section 
10.2. 

Step 2: Establish the search list. 

Enter : 

$DEFINE (LOGICAL NAME) DSK: DSK: .PS : <UETP. LIB> f^D 

NOTR 

The line loopback test is system 
dependent. If you are testing a 
DECSYSTEM-2040/50/60, perform Steps 3 
through 10. If you are testing a 
DECSYSTEM-2020, go to Step 11 and 
perform Steps 11 through 21. 

Step 3: Create a file for the DN20 node name. 

Create the file PS: <UETP.LIB>DNV2LN.NOD which specifies the name of 
the DN20 to be tested. The DN20 to be tested must be physically 
connected to the system on which this test is run. The name must be 
entered on the first line of the file being created and the name must 
not have terminating colons. Exit from EDIT with the EDIT command EU 
to remove the line numbers. An example is given. Substitute the name 
of your DECnet-20 communications front end for the DN20A in the 
example. Because the test cannot run without the file, both a 
DIRECTORY and a TYPE command are entered for checking purposes. 

Example : 



$conn ps : <uetp. lib> ( ret ) 
$edit dnv21n. nod QeT) 

%No such file type, Creating New file 
Input: DNV2LN.NOD.1 
00100 dn20aC«D 
00200 $ 
*eu( ret ) 



[DNV2LN.NOD.1] 

$dir dnv21n . nodQEi^) 

PS:<UETP.LIB> 
DNV2LN.NOD.1 
$type dnv21n . nod ( ret ) 
dn20a 
$ 
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Step 4: Create the file PS: <UETP. LIB>DNV2LN. LIN 

Create the file PS : <UETP.LIB>DNV2LN.LIN which specifies the DN20 lines 
to be tested. This file must contain a separate line of text for each 
hardware line to be tested. The line of text is the line 
specification in the form DDD_n_m where DDD represents the device 
type, n represents the controller number, and m represents the line 
number. Valid device types are KDP and DMC. (Because the DMC has 
only one line, the form is DDD_n.) The device DUP is valid for 32K 
front ends only. 

An example of a DNV2LN.LIN file creation follows. You must substitute 
the specifications of the hardware lines in your configuration. 
TEST72 in the front end requires that the line specifications be in 
uppercase as shown. Because the test will not run without the created 
file, the directory is checked and the file is typed. 

Example: 

$EDIT DNV2LN.LINQF) 

%No such file type, Creating New File 

Input: DNV2LN.LIN.1 

00100 KDP_0_0 GJD 

00200 KDP_0_1 C^ID 

0030 KDP_0_2 f^Q 

0040 KDP_0_3 C^P) 

00500 DMC_0Qir) 

00600 DMC-lfi^D 

00700 $ 

*EU C ret ) 

[DNV2LN.LIN.1] 

$dir dnv21n. linQlL) 

PS:<UETP.LIB> 
DNV2LN.LIN.1 
$type dnv21n. linQIE) 
KDP_0_0 
KDP_0_1 
KDP_0_2 
KDP_0_3 
DMC_0 
DMC_1 
$ 

Step 5: Ensure PS : <UETP.RUN> is empty. 
Enter: 



$CONNECT PS:<UETP.RUN>QeT 
$DELETE * .* C^ip 

Step 6: Run the UETP program. 

Enter : 

$RUN UETP C^O 
UETP> 
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Step 7: Enable test and begin testing. 

Enter : 

UETP> ENABLE DNV2LN/DEPTH : COMPREHENSIVE CUD 
UETP>BEGINQeT) 

Step 8: Respond to OPR messages. 

For each line to be tested, TWO messages are output to the operator's 
console. You will enter some commands and follow some given 
directions. Examples of the two messages follow. Not all numbers and 
names in the examples will duplicate what you see. Job name (X in the 
example) and line specification will reflect your testing parameters. 
The DN20A in the example should be replaced by the name of your 
DECnet-20 communications front end. As each line is tested, the two 
messages will be repeated until all lines to be tested have been 
addressed. 

Example - first message: 

OPR> 

11:25:47 <3> Batch-stream for JOB #11 — Message from Batch User — 

Job X Reg #17 for MIERSWA 

PLEASE TURN LINE OFF, CONNECT PLUG, TURN LINE ON: KDP_0_1 

OPR>ENTER NCPCmD 
NCP>SET EXECUTOR DN20AQ»D 
NCP>SET STATE LINE KDP_0_1 OFFQ«D 
NCP> 

11:26:27 NCP request # 2 [SET STATUS LINE KDP _ _ 1 OFF] 
Function completed successfully 

*** ATTACH LOOPBACK CONNECTOR NOW *** 
*** RETURN TO CONSOLE AND CONTINUE *** 

NCP>SET STATE LINE KDP_0_1 ONQJD 

NCP> 

11:30:23 NCP request # 3 [SET STATUS LINE KDP _ 0_ 1 ON] 

Function completed successfully 

NCP>RETURN ( ret ) 

OPR> RESPOND 3 OKQID 

OPR> 

(Test takes approximately 2 minutes) 

Example - second message: 

OPR> 

11:32:46 <4> Batch-stream JOB # 11 — Message from Batch 

User — 

Job X Req # 17 for MIERSWA 

PLEASE TURN LINE OFF: KDP_0_1 

OPR> ENTER NCPQfD 

NCP>SET EXECUTOR PN2QA CrIP ) 
NCP>SET STATE LINE KDP_0_1 OFFQID 
NCP> 

11:33:07 NCP request # 4 [SET STATUS KDP _ _1 OFF] 
Function completed successfully 

ncp>returnGID 
opr>respond 4 okqid 

OPR> 
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Step 9: When the test ends, check the RUN. LOG file. 

Enter : 

$TYPE RUN.LOGQID 

If the RUN. LOG file confirms the successful completion of the test 
(each of the lines you tested) , you have completed this test. Go to 
Section 10.3.4. If there are errors, continue with the next step. 

Step 10: Check the DNV2LN.LOG file. 

Enter : 

$TYPE DN V 2 LN. LOGGED 



Examine the output to determine the cause of the error. If any of the 
lines were successfully tested, repeat from Step 4 but include only 
the line specifications for lines that failed. If the test shows no 
lines tested successfully, repeat all steps beginning with the step 
referenced as in error in DNV2LN.LOG. 

Step 11: Turn lines off. 

The DECSYSTEM-2020 can be configured with 1 or 2 KDP DECnet 
communication lines. This test is to be run once for each line in 
your configuration. 

Use the NCP command subset of OPR to turn all lines off. For example, 
if your configuration includes 2 KDPs, 

Enter: 

$OPRCHD 

OPR>ENTER NCPQlD 

NCP>SET STATE LINE KDP_0_0 PEP CID 

NCP>SET STATE LINE KDP_0_1 OFF C^T") 

NCP>EXITQID 
$ 

Step 12: Install loopback connector. 

Install a loopback connector on line to be tested. See Section 10.3.1 
for description of loopback connector procedure. 

Step 13: Enable loopback and start line for cable loopback. 

Enter : 

$OPRQeD 

OPR>ENTER NCPQID 

NCP>SET LOCAL LOOPBACK ENABLED KDP_0_0 C^O 

NCP>SET STATE LINE KDP_0_0 CABLE-LOOPBACKQID 

NCP>EXITQeD 
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Step 14: Ensure that PS : <UETP. RUN> is empty. 
Enter: 



$CONNECT PS:<UETP.RUN>CEE 
$DELETE *.*Cre7 



Step 15: Run the UETP program. 
Enter : 



$RUN UETPQeT) 
UETP> 

Step 16: Enable tests and begin testing. 

Enter : 

UETP>ENABLE TEST7 2/DEPTH : COMPREHENSIVEQil 



uetp>enable dnv2ll/depth : comprehensive ftiq 
uetp>beginQeD 

Step 17: Examine the output from UETP. 

Only the DNV2LL test will end. TEST72 will not end by itself. If the 

STATUS reads Ended and the ERROR COUNT reads 0, the test was 

successful. If 1 or more errors are shown, continue to the end of the 

procedure, then repeat the test. If the test was successful, 
continue . 



Step 18: Abort TEST72 and exit. 

Enter : 

UETP>ABORT TEST7 2/DEPTH : COMPREHENSIVEQeT) 

UETP>EXITQeT) 

$ 

Step 19: Check the RUN. LOG file. 

Enter : 

$TYPE RUN. logQID 

If the RUN. LOG file confirms the successful completion of the test, go 
to Step 21. If there are errors, continue with the next step. 

Step 20: Check the DNV2LL.LOG file. 

Enter : 

$TYPE DNV2LL. LOGGED 

Examine the output to determine the cause of the error. Do not go to 
the next step. Repeat the test from Step 1, or, if it is clear from 
DNV2LL.LOG that the tests were enabled and begun, repeat from Step 14. 
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Step 21: Disable loopback testing for the first line. 

Enter : 

$OPRQiD 

OPR>ENTER NCPQID 

NCP>SET STATE LINE KDP_0_0 PEP CID 

NCP>SET LOCA L LOOPBACK DISABLED KDP_0_0GeD 

NCP>EXIT (~^T ) 

$ 

You have completed the line loopback testing for 1 line. If you have 
2 lines, repeat all from Step 12 (Install Loopback Connector). 



10.3.4 Remote-NCP Test 

The Remote-NCP test is executed in much the same way as the Local-NCP 
test. You use the OPR/NCP/ORION interface and may enter commands 
directly to your terminal or indirectly with a command file. 

In the previous two sections you have demonstrated that the Network 
Control Program functions on the local node (Section 10.3.2), and that 
the lines leading out of the local node are functioning (Section 
10.3.3). The purpose of the Remote-NCP test is to demonstrate that 
the OPR/NCP/ORION interface can be used to obtain information from the 
device controllers on remote nodes. 

Ensure that all loopback connectors are removed and the system is 
connected normally. 

If your host node is a DECSYSTEM-2040/50/60, reload the DECnet-20 
front end and log in with WHEEL or OPERATOR privileges enabled. Go to 
Step 1A if you wish to use direct input to your terminal; go to Step 
IB if you wish to use a command file. 

If your host node is a DECSYSTEM-2020 , reload the system and log in 
with WHEEL or OPERATOR privileges enabled. Go to Step 2A if you wish 
to use direct input to your terminal; go to Step 2B if you wish to 
use a command file. 

Step 1A. Remote-NCP test using direct terminal input 
(DECSYSTEM- 20 4 0/50/60) 



Enter : 



dp 



@enaBLEQ77) 

$conn ps : <uetp.decnet>C_^i_) 

$type remote-ncp-dn20-example . cmd ( ret ) 

Read the example file. Refer to the commands below the second line of 
asterisks. The ,, DN20" in the example SET EXECUTOR command is the node 
name of the DECnet-20 communications front end. You type the node 
name you assigned to the communications front end in the NETGEN 
procedures. For the SHOW STATUS LINE and SHOW COUNTS LINE commands, 
you type the line identification of each line in your configuration 
that you wish to test. 
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When you have executed the commands following the directions in the 
example, compare the output with the example below. The format should 
be similar. The node name and line identifications may differ. 

The TAKE commands that precede the NCP commands in the example are 
given to suppress printing of system and OPR messages during output. 
These commands are helpful if you are testing under timesharing, but 
are not needed if you are testing standalone. 

Example entry and responses: 

$take ref use ( ret ) 

OPR>take opr .cmd ( ret ) 

OPR> 

08:56:18 — OUTPUT DISPLAY for OPR Modified — 

OPR>enter ncpQID 

NCP>set executor dn20a C^~) 

NCP>show executorQFT) 

NCP> 

08:56:51 Current EXECUTOR is node DN20A 

NCP>show status local (~^r~) 

NCP> 

08:57:06 NCP request # 6 [SHOW STATUS LOCAL] 

Status of local node as of 6-Aug-79 08:57:06 

Node Name is DN20A, # 0, SYSTEM = KEL 4 EIELDTEST 3.0 18-JUL-79 
Routine version = 3.1.0, Communications Version = 3.1.0 
State is On, Default Host = 2102 

Function completed successfully 

NCP>show status known lines ( ret ) 

NCP> 

08:57:40 NCP request # 7 [SHOW STATUS KNOWN LINES] 

Status as of 6-Aug-79 08:57:40 

Line ID State Adjacent Node 

91 n? 



SYS880 
DN200 



DTE20_1_0_0 


On 


DMC11_0_0_0 


Off 


DMC11_1_0_0 


On 


DMC11_2_0_0 


On 


KDP_0_0_0 


On 


KDP_0_1_0 


On 


KDP_0_2_0 


On 


KDP_0_3_0 


Off 



Function completed successfully 
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NCP>show status line dmcll_0_OQED 

NCP> 

08:58:42 NCP request # 8 [SHOW STATUS LINE DMC11 __ _ 0] 

Status as of 6-Aug-78 08:58:41 

Line ID State Adjacent Node 

DMC11_0_0_0 Off 

Function completed successfully 



NCP>show status line kdp_0_0 ( ret ) 

NCP> 

08:59:18 NCP request # 9 [SHOW STATUS LINE KDP _ _ 0] 

Status as of 6-Aug-79 08:59:18 

Line ID State Adjacent Node 

KDP_0_0_0 On SYS880 

Function completed successfully 



NCP>show counts line dmc 1 1 _0_0 C_rjetJ 

NCP> 

08:59:52 NCP request # 10 [SHOW COUNTS LINE DMC11 _ _ 0; 

Counts for line DMC11_0_0_0, as of 6-Aug-79 08:59:52 

Seconds since zeroed 4296 

Blocks received 

Blocks sent 

Retran, line errors 

Received line errors 

Retran, not line errors 

Receive timeouts 

Function completed successfully 



NCP>show counts line kdp_0_0 ( «" ) 

NCP> 

09:00:29 NCP request # 11 [SHOW COUNTS LINE KDP _ 0_0] 

Counts for line KDP_0_0_0 , as of 6-Aug-79 09:00:29 

Seconds since zeroed 4334 

Blocks received 1 

Blocks sent 1 

Retran, line errors 

Received line errors 

Retran, not line errors 

Receive timeouts 

Function completed successfully 

NCP>show queue ncp-requests ( ret ) 

NCP> 

09:01:04 



There are no outstanding NCP requests. 



NCP>exit CRTT) 
End of REFUSE.CMD. 1 

9 
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If you wish to see an example of the same commands entered 
with a command file, type the file 
PS:<UETP.DECNET>REMOTE-NCP-DN20-EXAMPLE.TXT. You will see one major 
difference between direct and indirect entry. When commands are given 
using a command file, there will be a response to the SHOW QUEUE 
NCP-REQUESTS command. Because direct entry is at typing speed, the 
responses follow the commands and there are no commands waiting in the 
queue . 

If you wish to repeat the REMOTE-NCP test using a command file, 
continue with Step IB; otherwise go to Section 10.3.5. 

Step IB. Remote-NCP test using a command file (DECSYSTEM-2040/50/60) 

The file REMOTE-NCP.CMD in the directory PS : <UETP.DECNET> contains the 
commands for the REMOTE-NCP test. One SET EXECUTOR command, two SHOW 
STATUS LINE commands, and two SHOW COUNTS LINE commands are given with 
dummy arguments. These arguments must be edited to reflect the node 
name and line identifications of YOUR configuration. The number of 
both SHOW STATUS LINE and SHOW COUNTS LINE commands must equal the 
number of lines you plan to use for network traffic. The node name in 
the SET EXECUTOR command must be identical to the node name assigned 
to the DECnet-20 communications front end in the NETGEN procedures. 

The edited file should be output to PS: <UETP.LIB> as shown in the 

example. Use the EDIT command EU to remove line numbers when you exit 

from EDIT. Including the DN20 node name in the output file will help 

identify it for future use. 
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Example entries and responses: 



$edit 

Edit: 

*p~ :*( 

00100 

00200 

00300 

00400 

00500 

00600 

00700 

00800 

00900 

01000 

01100 

01200 

01300 

01400 

01500 

01600 

01700 

01800 

01900 

02000 

02100 

02200 

02300 

02400 

02500 

02600 

02700 

02800 

02900 

03000 

03100 

03200 

03300 

03400 

03500 

03600 

*snode- 

02800 

*sline$ 

03200 

*sline$ 

03300 

*sline$ 

03400 

*sline$ 

03500 

*p2800: 

02800 

02900 

03000 

03100 

03200 

03300 

03400 

03500 

03600 

*eu ( kei ) 



remote-ncp. cmd . 3 T (OUTPUT AS) ps : <uetp. 1 ib>remote-ncp-dn20a . cmdQ» 
REMOTE-NCP.CMD. 3 



*********************************************************************** 

THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY ONLY BE USED 
OR COPIED IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE. 

COPYRIGHT (C) 1978,1979 BY DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS 

DECnet-20 V2 Remote NCP test 

To run this test start OPR in a job enabled with wheel or operator 
privileges and enter the NCP command subset: 

@ENABLE 
$OPR 

OPR>ENTER NCP 
NCP> 

Then either enter: 

NCP>TAKE REMOTE-NCP.CMD 

to execute the statements in the command file or 
type the following commands by hand. 

*********************************************************************** 

SET EXECUTOR node-name 

SHOW EXECUTOR 

SHOW STATUS LOCAL 

SHOW STATUS KNOWN LINE 

SHOW STATUS LINE line 

SHOW STATUS LINE line 

SHOW COUNTS LINE line 

SHOW COUNTS LINE line 

SHOW QUEUE NCP-REQUESTS 
name$DN2 0A$28 00QED 

SET EXECUTOR DN20A 
DMC11 0$3200,EGET) 

SHOW STATUS LINE DMC11_0_0 
KDP 0$3300,EQED 

SHOW STATUS LINE KDP_0_0 
DMC11 0$3400,EdD 

SHOW COUNTS LINE DMC11_0_0 
KDP 0$3500,Ef^O 

SHOW COUNTS LINE KDP_0_0 
3600QlD 

SET EXECUTOR DN20A 

SHOW EXECUTOR 

SHOW STATUS LOCAL 

SHOW STATUS KNOWN LINE 

SHOW STATUS LINE DMC11_0_0 

SHOW STATUS LINE KDP_0_0 

SHOW COUNTS LINE DMC11_0_0 

SHOW COUNTS LINE KDP_0_0 

SHOW QUEUE NCP-REQUESTS 



[REMOTE-NCP-DN20A.CMD.!] 
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When you have exited from EDIT, 
Enter : 



CONN PS:<UETP.LIB>(reO 
$OPRQID 

opr>enter ncpQID 

NCP>TAKE REMOTE-NCP-xxxx.CMDQiD 

where xxxx is the node name of the DN20 
OUTPUT FOLLOWS 
Enter : 



NCP>EXITC_ret 
$ 

Check your output as the test is being performed. No error messages 
should be printed. The output should have the same format as the file 
REMOTE-NCP-DN20-EXAMPLE.TXT in PS : <UETP.DECNET> . This example is for 
a DECSYSTEM-2060 node with a DN20 node name of DN20A. Type the 
example file to compare it with your output. 

When the test completes successfully, go to Section 10.3.5. 

Step 2A. Remote-NCP test using direct terminal input (DECSYSTEM-2020) 
Enter : 

GenaBLE (CAPABILTIES)QiD 

$type ps : <uetp.decnet>remote-ncp-20-example . cmd Q^Q 

Read the example file. Refer to the nine commands below the second 
line of asterisks. To test YOUR local NCP, certain changes are 
required : 

The first command will be: 

SET EXECUTOR your local host name 

The node name in the SET EXECUTOR command must agree with 
the node name in the 4-CONFIG.CMD file in PS:<SYSTEM>. 

For both the SHOW STATUS LINE and SHOW COUNTS LINE commands, type 
the line identification (s) of the line(s) in your configuration 
that you wish to test. For one line, the lineid will be KDP_0_0. 
For two lines, the lineids will be KDP_0_0 and KDP_0_1. 

Now, type the commands (seven or nine commands depending on the number 
of lines) shown in the example, making the changes indicated for node 
name and lineids. Check the output as the commands are being 
performed. There should be no error messages. When the response to 
the last command is complete, type EXIT following the NCP prompt. 

To compare your output with an example, type the file 
PS:<UETP.DECNET>REMOTE-NCP-20-EXAMPLE.TXT. This example is the result 
of a TAKE command. If you wish to repeat the LOCAL-NCP test using a 
command file, go to Step 2B; otherwise go to Section 10.3.5. 
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Step 2B: Remote-NCP test using a command file (DECSYSTEM-2020) 



The file REMOTE-NCP.CMD i 
commands for the REMOTE- 
STATUS LINE commands, and 
dummy arguments. These 
name and line identificat 
both SHOW STATUS LINE 
number of lines you plan 
the SET EXECUTOR command 
in the 4-CONFIG.CMD file 



n the directory 
NCP test. One S 

two SHOW COUNTS 

arguments must 
ions of YOUR con 

and SHOW COUNTS 
to use for netwo 

must be identic 
in the installat 



PS:<UETP.DECNET> contains the 
ET EXECUTOR command, two SHOW 

LINE commands are given with 
be edited to reflect the node 
figuration. The number of 

LINE commands must equal the 
rk traffic. The node name in 
al to the node name specified 
ion procedures. 



The edited file should be output to PS: <UETP.LIB> as shown in the 
example. Use the EDIT command EU to remove line numbers when you exit 
from EDIT. 

Example entries and responses: 



$edit 
Edit: 
*p~ : * 
00100 
00200 
00300 
00400 
00500 
00600 
00700 
00800 
00900 
01000 
01100 
01200 
01300 
01400 
01500 
01600 
01700 
01800 
01900 
02000 
02100 
02200 
02300 
02400 
02500 
02600 
02700 



Qp 



remote-ncp. cmd . 2 (OUTPUT AS) ps : <uetp. 1 ib>r emote-ncp . cmd ( »n ) 
REMOTE-NCP.CMD. 2 



************************************************************** 

THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY ONLY BE USED 
OR COPIED IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE. 

COPYRIGHT (C) 1978,1979 BY DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS 

DECnet-20 V2 Remote NCP test 

To run this test start OPR in a job enabled with wheel or operator 
privileges and enter the NCP command subset: 

@ENABLE 
$OPR 

OPR>ENTER NCP 
NCP> 

Then either enter: 

NCP>TAKE REMOTE-NCP.CMD 

to execute the statements in the command file or 
type the following commands by hand. 

*********************************************************************** 
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02800 SET EXECUTOR node-name 

02900 SHOW EXECUTOR 

03000 SHOW STATUS LOCAL 

03100 SHOW STATUS KNOWN LINE 

03200 SHOW STATUS LINE line 

03300 SHOW STATUS LINE line 

03400 SHOW COUNTS LINE line 

03500 SHOW COUNTS LINE line 

03600 SHOW QUEUE NCP-REQUESTS 

*snode-name$4 09 7$28 0QiD 

02800 SET EXECUTOR 4097 

*sline$KDP_0_0$3 20 0,EGlD 

03200 SHOW STATUS LINE KDP_0^3 

*sline$KDP_0_l$3 30 0,EGHD 

03300 SHOW STATUS LINE KDP_0_1 

*sline$KDP_0_0$3400,E C^P ) 

03400 SHOW COUNTS LINE KDP_0_0 

*sline$KDP_0_l$3500,EQiD 

03500 SHOW COUNTS LINE KDP_0_1 

*p2800:3600QTr> 

2800 SET EXECUTOR 4097 

2900 SHOW EXECUTOR 

3000 SHOW STATUS LOCAL 

3100 SHOW STATUS KNOWN LINE 

3200 SHOW STATUS LINE KDP_0_0 

3300 SHOW STATUS LINE KDP_0_1 

3400 SHOW COUNTS LINE KDP_0_0 

3500 SHOW COUNTS LINE KDP_0_1 

3600 SHOW QUEUE NCP-REQUESTS 

*eu ( »n ) 

[<UETP.LIB>REMOTE-NCP.CMD.l] 
$ 



When you have exited from EDIT, 

Enter : 

$CONN_PS : <UETP . LIB>CreT) 

SOPR C^T) 

OPR>ENTER NCPQJD 

NCP>TAKE REMOTE-NCP.CMDQFT 

OUTPUT FOLLOWS 

Enter : 



NCP>EXITC_^I 
$ 

Check your output as the test is being performed. No error messages 
should be printed. The output should have the same format as the file 
REMOTE-NCP-20-EXAMPLE.CMD in PS : <UETP.DECNET> . This example is for a 
DECSYSTEM-2020. Type the example file to compare it with your output. 

When the test completes successfully, go to Section 10.3.5. 
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10.3.5 Remote and Local Node Network File Transfer Test 

This test ensures that the Network File Transfer (NFT) utility is 
functioning. The test is run under the control of the UETP program. 

Step 1: Log in as a nonpr ivileged user. 

NOTE 

If you are logging in to a directory other than the 
one you used for the verification procedures, remember 
to add the IPCF and USER GROUPS 100 parameters to the 
login directory. See Section 10.2 for help. 

Step 2: Create an NFT.INIT file in PS: <UETP.LIB> . 

The following example is for your guidance only. The parameters you 
use in the NFT command SET DEFAULTS must describe each node to which 
transfers will be made. You must have access to at least one account 
on each node to be tested. USER, ACCOUNT, and PASSWORD must have the 
values and format agreed upon by the remote node when the account was 
opened. 

The example assumes your file transfers will be between two nodes: 
2102, a DECSYSTEM-2060, and 4097, a DECSYSTEM-2020 . 

Example : 

@conn ps: <uetp. lib>QED 
@edit nf t . initQED 

%File not found, Creating New file 

Input: NFT.INIT.l 

00100 set defaults 2102: ; /user :gunn /account: 341/ostype: tops2 0/pass: zlinfm ( »» ) 

00200 set defaults 4097 : :/user :gunn/account : 341/ostype : tops20/pass : zlinfm (jjT) 

00300 $ 

*eU ( "ET ) 

[NFT.INIT.l] 

@type ps:<uetp.lib>nft. init ( «ti ) 

set defaults 2102:: /user :gunn/account : 341/ostype: tops20/pass: zlinfm 

set defaults 4097::/user :gunn/account : 3 41/ostype : tops20/pass : zlinfm 



See Chapter 8 if you need additional help in creating the NFT.INIT 
file. 
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Step 3: Check availability of nodes to be tested. 
Entry and response: 



@info decnet (_R£lJ 

Accessible DECNET nodes are: 1031, 2102, 4097, DN200, DN20A, 
DN20L, SYS880 

NOTE 

If the NFT test does not complete 
successfully the first time, it may be 
necessary to return to this step. (A 
node may have lost its "accessible" 
state.) 

Step 4: Define the file search association of DSK:. 

Entries and responses: 

@define utp: ps : <uetp. lib>(j<ET_) 
©define dsk: dsk : ,utp: ( ret ) 

Step 5: Connect to PS: <UETP.RUN> and pnsnrp that this directory is 
empty. 

Entries and responses: 

©connect ps: <ue tp.run>(j*ji_3 
©delete *.*QID 

DNV2FT.LOG. 1 [OK] 

EXCEPT. LOG. 1 [OK] 

RUN. LOG. 1 [OK] 

SEND. DAT. 1 [OK] 
©expunge <uetp. run>(_R£0 

PS:<UETP.RUN> [13 pages freed] 
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Step 6: Run UETP. 

Entries and responses: 

@run uetpQFT) 

[27-Sep-79 12:05:16 User Environment Test Package ] 



UETP>enable dnv 2ft /depth : application C^O 

[12:06:01 ENABLE COMPLETED] 

UETP >beg in r^FT) 

[12:06:09 BEGIN COMPLETED] 

UETP> 

START DNV2FT 12:06:35 
status 

[27-Sep-79 12:09:06] 



Test Depth 


Status 


Cycle 


Times 


Error 


Error 


Start 


name 






run 


count 


limit 


time 


===== ==== 




=== = 


= === 


= = = = = 


===== 


==== 


DNV2FT APP 


Running 


1 











27-Se 



END DNV2FT 12:12:07 
[All tests complete on processor # 2102] 
[27-Sep-79 12:13:25] 



Test Depth Status 
name 

DNV2FT APP Ended 



Cycle Times Error Error Start 
run count limit time 

110 27-Sep-79 12:06:09 



UEPT>exit C^D 

@dir C^T) 

PS:<UETP.RUN> 
DNV2FT.LOG. 1 
EXCEPT.LOG. 1 
RUN . LOG . 1 

TOTAL OF 3 FILES 
@type run. loq ( ^ ) 



START DNV2FT 
MINOR DNV2FT 
MINOR DNV2FT 
MINOR DNV 2 FT 
MINOR DNV2FT 
MINOR DNV2FT 
MINOR DNV2FT 
MINOR DNV2FT 
END DNV2FT 



27-Sep-79 12:0 

27-Sep-79 12:0 

27-Sep-79 12:0 

27-Sep-79 12:0 

27-Sep-79 12:0 

27-Sep-79 12:1 

27-Sep-79 12:1 

27-Sep-79 12:1 

27-Sep-79 12:1 



6: 


:35 


INIT 


0: 


:00: 


:025 


6: 


:51 


INIT 


0: 


:00: 


:059 


7: 


:03 


STPl 


0: 


:00: 


:081 


8: 


;57 


STP2 


0: 


:00: 


:154 


9: 


:42 


STP3 


0: 


:00: 


:215 


0: 


:22 


STPl 


0: 


:00: 


:236 


li 


:51 


STP2 


0: 


:00: 


:319 


2: 


:05 


STP3 


0: 


:00: 


:369 


2: 


:07 


FIN 


0: 


:00: 


:379 



:25:51DNV2FT started 
:52:01DNV2FT finished step INIT 

3:07:19DNV2FT finished step STPl 

4:55:22DNV2FT finished step STP2 

7:25:28DNV2FT finished step STP3 

8: 30:31DNV2FT finished step STPl 

3:04:20DNV2FT finished step STP2 

7:01:03DNV2FT finished step STP3 
7: 39:22DNV2FT ended 
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If the test ends with errors, typing the RUN. LOG file displays for 
each node tested: 

finished STP1 
finished STP2 
finished STP3 

In the example, two nodes were tested. The six lines confirm the 
successful completion of the test. If the error count is 1 or more, 
type the DNV2FT.LOG file. All steps and errors are displayed in 
detail. This file will also be helpful if you plan to create your own 
NFT test. If you could not run UETP, check your directory for the 
IPCF and USER GROUP 100 entries and check your define statements. 



10.3.6 DN200 Tests (2040/50/60 with Remote Job Entry Station Only) 

This test demonstrates the use of Operator Commands (OPR) at the DN200 
remote station console. The test includes queueing output to be 
printed by the printer at the remote station and executing a batch job 
from the remote station. The batch job includes reading the card 
deck, executing the batch program, and printing the batch log. 

Prior to this test, the DN200 must have been configured as part of the 
local DECn*?t— 20 svstem * The DN200 must have been verified, powered on 
and loaded. 

Step 1: Check the DN200 status and queue status at operator's 
console . 

Entries and Responses: 

2102: :OPR>SHOW STATUS C^O 

2102: :OPR> 

2102: : 

9:13:05 — System Device Status — 

Printer Status: 

Unit Node Status 



DN200 Idle 
Reader Status: 

Unit Node Status 

DN200 Idle 



2102: :OPR>SHOW Q(J*T) 

2102: :OPR> 

2102:: 

9:13:40 — The Queues are Empty — 

2102: :OPR> 
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Step 2: Print file on local and remote (DN200) printers and compare. 
(First ensure the DN200 is available.) 

Entries and responses: 

C ESC ) C E* ) 

@infORMATION (ABOUT) decNETdD 

Accessible DECNET nodes are: 1031, 2102, 4097, DN200, DN20A, DN20L 
@print ps:<uetp.lib>pictur.txt (RET) 
[Job PICTUR Queued, Request-ID 89, Limit 54] 
@print ps: <uetp. lib>pictur . t xt/destinat ion-node :dn 200: : C ret ) 
[Job PICTUR Queued, Request-ID 90, Limit 54] 

( ESC ) ( ESC ) 

^INFORMATION (ABOUT) OUTPUT-REQUESTS QZD 



Printer Queue: 
Job Name Req# Limit User 



* PICTUR 90 54 CIRINO On Unit:0 /Dest:DN200 

Started at 10:55:21, printed of 54 pages 

6201DP 6 810 HARAMUNDANIS /Lower /Forms .-NARROW 

DN6A 2 108 LNEFF /Lower /Forms :NARROW 

There are 3 Jobs in the Queue (1 in Progress) 

The output is a geometric pattern. Any errors in transmission will be 
easily seen. 

Step 3: Prepare a card deck for submission to the DN200 card reader. 

Keypunch entries: 

$JOB username 

$PASSWORD password 

$TOPS20 

@DEFINE DSK: DSK : , <UETP.RUN> , <UETP . LIB> 

@PRINT CHARS.TXT 

$EOJ 
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Step 4: Read the deck on the DN200 card reader. 

Output on DN200 console: 

2102: :OPR>SHOW STATUS C^O 
2102: :OPR> 
2102: : 



9:27:13 

Printer Status: 
Unit Node 



— System Device Status — 



Status 



DN200 Idle 



Reader Status: 
Unit Node 



Status 



2102: :OPR> 
2102: : 
9:29:34 

2102:: 
9:29:37 



2102: :OPR> 
2102: : 
9:29:49 



2102:: 
9:29:51 

2102: : 
9:29:51 



2102: :OPR> 
2102:: 
9:31:54 



2102: : 
9:31:54 



2102: :OPR> 
2102: : 
9:32:56 



2102: :OPR> 



DN200 Idle 



Reader [DN200] — 1 Job: 7 Cards Spooled — 



Batch-Stream 2 —Begin — 
Job JB3047 Req #38 for CIRINO 



Batch-Stream 2 — End — 

Job JB3047 Req #38 for CIRINO 



Printer [DN200] — Started — 



Printer [DN200] — Begin — 
Job CHARS Req #39 for CIRINO 



Printer [DN200] —End- 
Job CHARS Req #39 for CIRINO 



Printer [DN200] —Begin — 
Job JB3047 Req #40 for CIRINO 



Printer [DN200] — End — 
Job JB3047 Req #40 for CIRINO 



The SHOW STATUS command is given to check the immediate availability 
of the reader and printer. All of the output that follows is 
displayed without further action by the operator. Req #38 is for the 
read; Req #39 is for the printing of the CHARS.TXT file; Req #40 is 
for the printing of the log file. 
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Output on the DN200 printer is a five-page printout of the complete 
character set extending margin to margin with each successive line 
offset one space to the left. The printout of the batch log file 
completes the job. The log file printout should resemble the 
following example: 



SPRINT version 104(4072) 2102 Development System, 
TOPS-20 Monitor 4(3117) 



Example: 




9: 


29: 


35 


STDAT 


9: 


:29: 


35 


STMSG 


9: 


:29: 


35 


STCRD 


9: 


:29: 


35 


STCRD 


9: 


:29: 


35 


STCRD 


9: 


:29: 


35 


STCRD 


9: 


:29: 


35 


STSUM 


9: 


:29: 


35 


STSUM 


9: 


:29: 


35 


STSUM 



[Job Input from Reader 

$JOB CIRINO 

$ PAS SWORD 

$TOPS20 

$EOJ 

End of job encountered 

7 Cards Read 

Batch job submitted 



[DN200]] 



26-Sep-79 9:29:37 
BATCON Version 104(4126) GLXLIB Version 1(515) 

Job JB3047 Req #38 for CIRINO in Stream 2 



OUTPUT: Log 
UNIQUE: Yes 
RESTART: No 



Input from => PS : <CIRINO>JB304 .CTL. 1 
Output to => PS:<CIRINO>JB3047.LOG.l 



TIME-LIMIT: 0:05:00 

BATCH-LOG: Append 

ASSISTANCE: Yes 

SEQUENCE: 1624 



2102 Development System, TOPS-20 Monitor 4(3117) 
@SET TIME-LIMIT 300 
@LOGIN CIRINO 341 

Job 50 on TTY222 26-Sep-79 09:29:42 
@ 
[PS Mounted] 

[CONNECTED TO PS:<CIRINO>] 

@DEFINE DSK: DSK : , <UETP. LIB> 

@@CONN <UETP.RUN> 

@@PRINT CHARS.TXT 

[Job CHARS Queued, Request-ID 39, Limit 54] 

@ 

%FIN: : 

Killed Job 50, User CIRINO, Account 341, TTY 222, 
at 26-Sep-79 09:29:47, Used 0:00:00 in 0:00:05 



DECnet Error and Event Logging Test 

This test demonstrates the error and event logging features of DECnet. 
While you were performing the previous tests, DECnet was writing 
entries into the system log. SYSERR can be used to examine these 
entries. Refer to Appendix C for a detailed description of SYSERR 
entr ies. 



9: 


29: 


:38 


USER 


9: 


29: 


:38 


MONTR 


9: 


29: 


:38 


MONTR 


9: 


29: 


:42 


MONTR 


9: 


:29: 


:42 


MONTR 


9: 


:29: 


:42 


MONTR 


9: 


;29: 


:42 


MONTR 


9: 


:29: 


:42 


MONTR 


9: 


:29: 


:42 


MONTR 


9: 


:29: 


:44 


MONTR 


9: 


:29: 


:44 


MONTR 


9: 


;29: 


:46 


MONTR 


9: 


;29: 


:47 


MONTR 


9: 


:29: 


:47 


BLABL 


9: 


:29: 


:47 


MONTR 


9: 


:29: 


:48 


MONTR 


9: 


:29; 


:48 


MONTR 


10 


.3. 


7 


DECnet 
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The following commands output to the printer a summary of all entries 
concerning your network. The /BRIEF switch creates a listing 
containing the sequence number, the time of the occurrence, and a 
maximum of three lines of the most usable information for each entry. 
Output may be directed to your terminal by typing TTY:= in place of 
LPT:=. 

Enter : 



@ SYS ERR (TIT) 

*LPT: =/BRIEF/NETALLQiD 

Examine the output. If you need further help in interpreting the 
entries, the following sources will be helpful: 

• Appendix C of this manual 

• TOPS-10 and TOPS-20 SYSERR Manual 

• HELP file for SYSERR 

To obtain a detailed listing of the entries summarized in the first 
listing , 



Enter : 



@SYSERR QeD 



+ TTim--_ /T*ir-»m7* "tt /■ninm'RTT 

uxr i . — / i>Lirti j_i/ lv Lj inijij 1 



Examples of SYSERR output may be printed from PS: <UETP.DECNET> . The 
example files are BRIEF.TXT and DETAIL.TXT. 

The HELP file for SYSERR contains information on switches for use with 
SYSERR. For example, you can request listings for specific sequence 
numbers or specific dates. 
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APPENDIXES 



APPENDIX A 
DISCONNECT OR REJECT CODES 



The disconnect or reject codes in Table A-l are defined by NSP and are 
sent and retrieved by network tasks via the network functions of the 
MTOPR monitor call. 



Table A-l 
Disconnect or Reject Codes 



S Tr mbo 1 


Va 1 u e 


Moan i n n 


.DCXO 





No special error 




.DCX1 


1 


Resource allocation failure 




.DCX2 


2 


Destination node does not exist 




.DCX3 


3 


Node shutting down 




.DCX4 


4 


Destination process does not exist 




.DCX5 


5 


Invalid name field 




.DCX6 


6 


Destination process queue overflow 




.DCX7 


7 


Unspecified error 




.DCX8 


8 


Third party aborted the logical link 




.DCX9 


9 


User abort (asynchronous disconnect) 




.DCX11 


11 


Undefined error code 




.DCX21 


21 


Connect initiate (CI) with illegal destination 






address 




.DCX24 


24 


Flow control violation 




.DCX32 


32 


Too many connections to node 




•DCX33 


33 


Too many connections to destination process 




.DCX34 


34 


Access not permitted 




.DCX35 


35 


Logical link services mismatch 




.DCX36 


36 


Invalid account 




.DCX37 


37 


Segment size too small 




.DCX38 


38 


Process aborted 




.DCX39 


39 


No path to destination node 




.DCX40 


40 


Link aborted due to data loss 




.DCX41 


41 


Destination logical link address does not ex 


ist 


.DCX42 


42 


Confirmation of disconnect initiate (DI) 




.DCX43 


43 


Image data field too long 
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APPENDIX B 
DECnet OBJECT TYPES 

The object types listed in Table B-l are taken from the Network 
Services Protocol, Version 3.1 documentation. Object type codes are 
expressed in decimal. DECnec-20 will, in addition, recognize a nuniuet 
of object names in place of object types. Object names that are 
currently supported are shown in Table B-l. 

Object type (TASK) can only be used by a source task in order to 
address a target task. Object types 1 through 127 can be used by any 
system task; however, the task must have WHEEL or OPERATOR privileges 
enabled. Object tvpes 128 throunh 255 are available to =>11 n .fi"w^rl' 
tasks. 



Table B-l 
DECnet Object Types 



Object 
Type 
Code 


Object 
Name 


Function 




1 

2 

3-4 

5 

6 

7 

8-14 

15 

16 

17 

18 

19 

20-62 

63 

64-127 

128-255 


TASK 

NRM 

FAL 
NCU 


General task, user process 

File Access (FAL/DAP-Version 1) 

Unit Record Services 

Reserved for DECnet use 

RSX-llM Task Control-Version 1 

Reserved for DECnet use 

Node Resource Manager 

Reserved for DECnet use 

RSX-llM Task Control-Version 2 

System TALK Utility 

File Access (FAL/DAP-Version 4) 

RSX-llS Remote Task Loader 

NICE process 

Reserved for DECnet use 

DECnet Test Tool (DTR) 

Reserved for DECnet control 

Reserved for customer extensions 
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APPENDIX C 
NETWORK EVENT AND ERROR LOGGING 



C.l OVERVIEW 

Error and event logging as described in this appendix is available 
only for DECSYSTEMs-2040/50/60 with a minimum of 128K words in the 
DN20 DECnet communications front end. (Significant events on a 
DECSYSTEM-2020 DECnet system are displayed as BUGCHKs or BUGINFs on 
the operator's console and are logged in the SYSERR file.) 

One of the functions performed by the network control task (NETCON) is 
to record pertinent network events as SYSERR entries to the system's 
ERROR. SYS file. The following events are recorded each time they 
occur : 

• Load and start NETCON 

• Load a node 

• Dump a node 

SYSERR entries are also created for: 

• hardware detected failures 

• CHK11 diagnostic messages 

In addition, you can optionally request NETCON to periodically log 
line-counter values and error statistics for any communications line 
terminating on any node in the network. See the Operator Commands in 
Section 6.3 for a description of the following commands: 

INITIATE LOGGING LINE-COUNTERS lineid nodename 

TERMINATE LOGGING LINE-COUNTERS lineid nodename 

SET LOGGING-INTERVAL LINE-COUNTERS n (MINUTES) 

Note that this feature is a DECnet-20 function; all SYSERR entries, 
regardless of which line or node they are recorded for, are entered 
into the ERROR. SYS file residing at the DECnet-20 node that processes 
the INITIATE LOGGING command. 

To obtain a formatted printout of all or selected portions of the 
ERROR. SYS file, use the SYSERR program described in the TOPS-10 and 
TOPS-20 SYSERR Manual. 
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NETWORK EVENT AND ERROR LOGGING 

C.2 SYSERR ENTRIES 

Each of the SYSERR entries described below consists of two parts: 

1. A 4-word header section 

2. A variable-length body section 

The format of the header section is the same for all entries; the 
format of the body section varies by the type of event being logged. 

The header section is comprised of four words that provide general 
information about the system, the time and type of event, and the 
length of the entry. The format and contents are shown in Figure C-l. 



Symbol Offset 



89 



16 17 18 



23 24 



26 27 



*This entry recorded by TOPS-20 

'* A 36-bit quantity with a binary point between the left and right halves. 
The left half is the number of days since 1 7 November 1 858; the right 
half is the fraction of a day in Greenwich Meridian Time. 



35 



HDRCOD 


(0) 
(1) 
(2) 
(3) 


Event type 


Reserved 


* 


Header 
format 


Header 
length 


Body 
length 


HDRDAT 


Date and time in Universal Format** 


HDRUPT 


System uptime (whole days) 


System uptime (frac. days) 


HDRPSN 


Processor serial number where the entry was recorded 



MR-S-603-80 



Figure C-l Common Header Section for SYSERR Entry 



C.2.1 NETCON Load Entry (event 201) 

Whenever NETCON is loaded and started, a SYSERR entry is made to 
record the version number and the node on which NETCON is running. 
The format and contents are shown in Figure C-2. 
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Symbol Offset 
HDRCOD (0) 



NS%VER (4) 
NS%NAM (5) 
NS%PGM (6) 



I 



t_ 



NETWORK EVENT AND ERROR LOGGING 



201 



(Header section) 



NETCON version number 



Offset to the ASCIZ node name of host 



Offset to the ASCIZ program name 



ASCIZ node name of host 



ASCIZ program name 



Figure C-2 SYSERR Entry for a NETCON Load 
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i 



j 



MR-S-604-80 
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NETWORK EVENT AND ERROR LOGGING 



C.2.2 Node Load Entry (event 202) 

Whenever NETCON loads a node, a SYSERR entry is made to record 
information such as the nodes involved, the line used, the load file 
specification, and any return code. The format and contents are shown 
in Figure C-3. 



Symbol Offset 
HDRCOD (0) 



NL%TAR 


(4) 


NL%SER 


(5) 


NL%SLD 


(6) 


NL%FIL 


(7) 



NL%RTN (10) 



T_ 



202 



(Header section) 



Offset to the ASCIZ name of the node being loaded 



Offset to the ASCIZ name of the node doing the loading 



Offset to the ASCIZ line identification 



Offset to the ASCIZ load file specification 



Return code 



ASCIZ name of the node being loaded 



ASCIZ name of the node doing the loading 



ASCIZ line identification 



ASCIZ load file specification 
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Figure C-3 SYSERR Entry for a Node Load 



I 



MR-S-605-80 
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C.2.3 Node Dump Entry (event 203) 

Whenever NETCON dumps a node, a SYSERR entry is made to record 
information such as the nodes involved, the line used, the dump file 
specification, and any return code. The format and contents are shown 
in Figure C-4. 



Symbol Offset _0_ 
HDRCOD (0) 



ND%TAR (4) 

ND%SER (5) 

ND%SLD (6) 

ND%FIL (7) 

ND%RTN (10) 



T 



£ 



203 



(Header section) 



Offset to the ASCIZ name of the node being dumped 



Offset to the ASCIZ name of the node receiving the dump 



Offset to the ASCIZ line identification 



Offset to the ASCIZ dump file specification 



Return code 



ASCIZ name of the node being dumped 



ASCIZ name of the node receiving the dump 



ASCIZ line identification 



ASCIZ dump file specification 
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Figure C-4 SYSERR Entry for a Node Dump 
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C.2.4 Hardware Error Entry (event 210) 

Whenever a hardware option detects a failure, a SYSERR entry is made 
to assist in the network maintenance function. The information 
recorded includes the environment of the entry, the hardware option 
that detected the error, the software running in the node where the 
error is detected, and a detailed log data description of the hardware 
option reporting the failure. The format and contents of the hardware 
error entry are shown in Figure C-5. 
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Symbol Offset 
HDRCOD (0) 



(4) 



NH%MID 
NH%MID 
NH%RID 
NH%ADN 

NH%FUN (10) Reserved 
NH%NUM 
NH%SEQ 

NH%LID 

NH%LI1 
NH%DAT 
NH%TRY 
NH%RSM 
NH%PTR 



(5) 
(6) 
(7) 



(11) 
(12) 
(13) 
(14) 
(15) 
(16) 
(17) 



(20) 



210 



(Header section) 



Transmitting node number 



Destination node number 



Offset to ASCIZ transmitting node name 



Offset to ASCIZ receiving node name 



Offset to ASCIZ adjacent node name (-1) 



Hdw sys. 



Oper. sys. 



Hdw option* 



Number of 8-bit bytes in log data section 



Hardware entry sequence number 



Controller number 



reserved 



Line or unit number 



Station number 



Node uptime when error detected 



Flags 



reserved 



Threshold value 



Retry count 



Code (reason) 



Offset to start of log data 



3fr 



ASCIZ transmitting node name 



^ 



ASCIZ receiving node name 



ASCIZ adjacent node name 



Delay counter & UNIBUS address 
PYtpnsinn hits 



Deposit/examine word # 2 



KL10 memory additional word # 1 



To -10 byte count 



To -10 address 



To -10 data word 



Diagonal/control register # 1 



Control/status register 



Deposit/examine word # 3 



Deposit/examine word # 1 



-St 



KL10 memory additional word § 2 



To -1 1 byte count 



To 1 1 address 



To -1 1 data word 



Diagonal/control register § 2 



Diagonal/control register # 3 



Log 
> data 



*The hardware option field determines the content of the log data. Log data above is 
according to hardware option = DTE20 (015). mr-S-607-80 



Figure C-5 SYSERR Entry for Hardware Detected Failures 
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Log data for hardware option KMC11/DUP11 (003). 
for this hardware option type follows. 



The initial 21 bytes 



Offset to first word of sub-device table 


Input transfer & maintenance Output transfer 
control/status register j control/status register 


1st half of data port 


2nd half of data port 





Microcode 
type 





Microcode 
version 










i 





MR-S-608-80 



Figure C-5.1 Log Data for KMC11/DUP11 



Receiver status register 


Receiver data buffer register 


Transmitter status register 


Transmitter data buffer register 



MR-S-609-80 

Figure C-5.2 Sub-device Table for Hardware Option DUPll (003] 
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C.2.5 CHK11 Diagnostic Entry (event 220) 

CHKll, a hardware test module, is started when the DN20 or DN200 is 
loaded. All messages from CHK11, messages concerning available 
memory, and number and status of devices as well as detected errors, 
become part of the CHKll diagnostic entry. 

The format of the environment and reporting device section that 
follows the header and precedes the log data section is the same as 
that for event 210 (hardware error entry.) Symbols NH%MID through 
NH%PTR become NO%MID through NO%PTR. The log data is an ASCIZ CHKll 
message of arbitrary length. The format and contents are shown in 
Figure C-6. 



Symbol Offset 
NO%MID (4) 
NO%PTR (20) 



220 



(Header section) 



Words NO%MID through NO%PTR are 
the same as words NH%MID through 
NH%PTR (event 210, Hardware entry) 



ASCIZ transmitting node name 



-C 



ASCIZ receiving node name 



ASCIZ adjacent node name 



ASCIZ - 
CHK11 - 

message 



(length depends on specific message) 



MR-S-610-80 

Figure C-6 SYSERR Entry for CHKll Diagnostic Entry 
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C.2.6 Line Status Entry (event 230) 

Periodically, NETCON records the status of each communications line 
via a SYSERR entry. The information that is logged includes the node 
name, line identification, and a variable number of line counters. 
The format and contents are shown in Figure C-7. 



Symbol Offset 
HDRCOD (0) 



LC%MID 


(4) 


LC%XID 


(5) 


LC%RID 


(6) 


LC%ADN 


(7) 


LC%FUN 


(10) 


LC%NUM 


(11) 


LC%SEQ 


(12) 


LC%LID 


(13) 


LC%LI1 


(14) 


LC%DAT 


(15) 


LC%TRY 


(16) 


LC%RSM 


(17) 


LC%PTR 


(20) 
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230 



(Header section) 



Transmitting node number 



Destination node number 



Offset to ASCIZ transmitting node name 



Offset to ASCIZ receiving node name 



Offset to ASCIZ adjacent node name (-1 ) 



reserved 



Flags 



Hdwe system 



Oper. system 



Hdwe option 



Number of 8-bit bytes in log data section 



Hardware entry sequence number 



Controller number 



reserved 



Line or unit number 



Station number 



Node uptime when error detected 



reserved 



Retry count 



Reason for entry 



Offset to start of log data 



ASCIZ transmitting node name 



ASCIZ receiving node name 



Type of counter 



Type of counter 



Counter value 



Counter value 



Type of counter 



Counter value 



^L 



Figure C-7 SYSERR Entry for Line Statistics 



MR-S-611-80 
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The line counter entries are in half-word format, with the line 
counter type (0-10 octal) in the left half and the item count in the 
right half. The current line counter types are described in Table 
C-l. The number of line counter values that are actually recorded 
depends on the type of controller on the line. 



Table C-l 
Line Counter Types 



Type 


Count of 


Meaning 


(Octal) 









seconds since last zeroed 


This count is incremented 
once a second. It is 
cleared when the other 
counters are cleared and 
thus provides a time frame 
for their values. 


1 


blocks received 


This is the number of blocks 
successfully received over 
the line. 


2 


blocks sent 


This is the number of blocks 
successfully sent over the 
line. 


3 


retransmissions, line errors 


This is the number of blocks 
retransmitted because of CRC 
or parity errors. 


4 


received line errors 


This is the number of blocks 
received with CRC or parity 
errors. 


5 


retransmissions, other than 


This is the number of blocks 




errors or parity 


retransmitted for reasons 
other than CRC or parity 
errors. 


6 


receive timeouts 


This is the number of times 
the receive timer has 
expired . 


7 


receive selection errors 


This is the number of times 
blocks have been received 
with invalid selection data. 


10 


resource errors 


This is the number of times 
such things as buffers have 
not been available. 
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APPENDIX D 
BIBLIOGRAPHY 



The following DIGITAL documents contain detailed information on the 
protocols used in DECnet. 

DECnet DIGITAL Network Architecture: 

Digital Data Communications Message Protocol (DDCMP) AA-D599A-TC 

Network Services Protocol (NSP) AA-D600A-TC 

Data Access Protocol (DAP) AA-D6Q1A-TC 

Maintenance Operation Protocol (MOP) AA-D602A-TC 

The following published books are a source of general network 
information. The list is both arbitrary and abbreviated and is 
intended to be a catalyst to stimulate the reader's interest. 

Title Author Publisher 



Introduction to Data Murphy and DIGITAL 

Communications Kalis 

Introduction to Mini- — DIGITAL 

Computer Networks 

Technical Aspects of McNamara DIGITAL 
Data Communications 

Introduction to Tele- Martin Prentice-Hall 
Processing (and others) 

Basics of Data Karp, ed . McGraw-Hill 
Communications 

Communications Networks Davies and Wiley and Sons 

for Computers Barker 

Handbook of Data Editors National Computing 
Communication's " Centre Publications 

(United Kingdom) 

Data Communications Doll Wiley Interscience 
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APPENDIX E 
GLOSSARY 



acceptance tests 



asynchronous transmission 



certification procedure 



computer network 



configuration 



configuration tools 

connect 

connect password 



Acceptance tests refer to the 
verification and certification 
procedures . 

Transmission in which the time intervals 
between transmitted characters may be of 
unequal length because each character 
^ont 3 ins i^s 
This is also 
transmission . 



n cf arf ar>/^ efnn Ki fe 

known as start/stop 



The DECnet certification procedure 
ensures that the various components of 
the DECnet-20 system function at a 



basic, minimal level, 
certification procedure 
after the DECnet 
installation, and 
procedures are performed. 



The DECnet 

is performed 

configuration , 

verification 



An interconnection of computer systems, 
I/O devices, and communications 
facilities. 

The process of customizing the 
DECSYSTEM-2040/50/60. Using the 
configuration tools, the DECnet user 
establishes the network parameters 
specific to the DECnet communications 
front end (and RJE station, if included) 
being configured. 

The programs NETGEN, TKB20, VNP20, and 
DNMAC. These are the programs needed 
for on-site configuration of DECnet-20 
on a DECSYSTEM-2040/50/60. 

The process of creating a logical link. 

A 1- to 8-character password used to 
validate access privileges between tasks 
on a network. 
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DAP (Data Access Protocol) 



data transmission 



DDCMP 



disconnect 
DMC11 

DN2 



A set of standardized formats and 
procedures that facilitate the creation, 
deletion, transfer, and access of files 
between a user process and a file system 
existing in a network environment. 

The sending of data from one computer to 
another over a physical link, or from 
one task to another over a logical link. 

Digital Data Communications Message 
Protocol. A formal set of conventions 
designed to provide error-free, 
sequential transmission of data over 
physical links. 

The process of closing a logical link. 

A single line microprocessor-based 
interface to the network. The DMC11 is 
a synchronous DMA device. 

A DECnet-20 communications front end. 

As used in this manual, DN20 is a 

generic term and includes both the DN20 
and the DN21. 



DNMAC 



The DNMAC program is the cross assembler 
for PDP-11 macro source files. 



down-line loading 



Transmitting a program's memory image 
over a logical link and loading and 
starting the program on a computer at 
another node. 



DTE 



The hardware interface between the main 
processor in a DECSYSTEM-2040, 2050, or 
2060 and the PDP-11 processor in the 
DN20 communications front end. 



duplex 



FAL (File Access Listener 



full-duplex 
half-duplex 

host computer 



Simultaneous independent transmission in 
both directions. Also referred to as 
full-duplex or two-way simultaneous. 

The FAL program resides on a DECnet host 
and acts as the target for requests made 
by the NFT programs residing on remote 
DECnet hosts. The FAL program is 
responsible for determining a user's 
access privileges to a requested file 
and the subsequent honoring or rejecting 
of the request. 

See duplex. 

Transmission in either direction, but 
not in both directions simultaneously. 
Also referred to as two-way alternate. 

A computer at a network node that 
primarily provides services such as 
computation, data base access, special 
programs, or programming languages to 
other nodes in the network. 
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installation procedure 



interrupt message 
local node 

local NSP 
local task 
logical link 

logical node 



loop-back 



DECnet installation is the process of 
setting up the DECnet software and 
modifying several system files to 
include DECnet-related jobs. DECnet 
installation occurs after DECnet 
configuration. 

A high-priority message used to inform 
another task of some significant event. 

A relative term indicating the node at 
which your task is executing or at which 
your terminal is logged in. 

NSP executing in the local node. 

A task executing at a local node. 

A virtual data path between two tasks in 
a network that permits them to 
communicate. 

The logical node is the node to which 
the system sends a user's queued output. 
At login time, the logical node is the 
same as the ohysical node. The user may 
specify a logical node by using the SET 
LOCATION command from TOPS-20 command 
level . 

A mode of operation where data 
transmitted by a network task is 
reflected at some point along the 
communication path and is returned to 
the originating task. 



modem 



In networks, a device that makes 
computer signals compatible with 
communications facilities. 



MOf 



NCP 



NCU 



Maintenance Operation Protocol. A 
formal set of messages and rules used to 
load and dump computer memory as well as 
test a communications link between two 
adjacent nodes. 

NCP is the name of the network control 
program that processes DECnet-20 network 
control commands. NCP refers to one of 
the three major programs of NETCON. 

NCU is the name of the network control 
utility that executes network control 
commands. NCU implements the Network 
Information and Exchange (NICE) 
protocol. NCU refers to one of the 
three major programs of NETCON. 
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NETCON 



NETCON is a specialized network control 
task that accepts requests via operator 
commands and command files. NETCON 
processes network control requests such 
as the loading or dumping of 
communications front end software, the 
loading or dumping of synchronous line 
controllers, the displaying of line 
statistics for any line, etc. See 
Sections 1.4 and 1.6 in Chapter 1 for 
details. 



NETGEN 



NETGEN is the interactive program used 
to describe the hardware and software 
during the configuration procedure for a 
DECnet node. 



network 



An interconnected or interrelated group 
of nodes. In this manual, network is 
synonymous with computer network. 



network dialogue 



An exchange of information between two 
tasks in a network. 



network task 



A task engaged in, or willing to engage 
in, a network dialogue. In NSP 
documentation, a network task is also 
referred to as a network object. 



NFT (Network File Transfer) 



NICE protocol 



A program that allows you to access or 
delete files residing on DECnet hosts 
that provide network file access 
capabilities. NFT initiates the service 
requests that will be carried out by the 
FAL program. 

NICE is the acronym for the Network 
Information and Control Exchange 
protocol that enables various DIGITAL 
computers to access the information and 
control facilities of remote nodes on 
the same network. 



node 



An endpoint of any branch of a network, 
or a junction common to two or more 
branches of a network. In this manual, 
the DECSYSTEM-20 and any communications 
front ends are all considered nodes. 



node name 



node number 



A 1- to 6-character name uniquely 
identifying a node within a network. 
Node names can be any combination of the 
characters A through Z, and through 9. 

A number uniquely identifying a node 
within a network. Although NSP allows 
node numbers of 2 through 240, DECnet-20 
nodes may only be assigned numbers 2 
through 127. 
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NSP 



OPR 



ORION 



Network Services Protocol. A formal set 
of conventions used in DECnet to perform 
network management and to exchange 
messages over logical links. NSP also 
refers to the program that implements 
the NSP protocol. (In the text, NSP 
refers to the program; NSP protocol is 
used to refer to the protocol.) 

OPR is the Operator Command Language 
program that provides the operator with 
one command language to communicate with 
several TOPS-20 components. OPR 
processes commands for syntax and passes 
syntactically correct commands to ORION. 
(See the ORION definition.) 

ORION is the operator control program 
that accepts commands from OPR and 
forwards the commands to the proper 
program for execution. ORION forwards 
NCP commands to NETCON. 



packet 



physical link 



A group of bits, comprising data and 
control information, which is 
transmitted as a composite whole over a 
physical link. The data, control, and 
possibly error control information are 
arranged in a specified format. (The 
basic transmission unit of DDCMP) . 

A communications path between two 
adjacent nodes. This can be in the form 
of a dial-up line, leased line, radio, 
satellite link, or a channel-to-channel 
connector such as a DTE. 



physical node 



A physical node consists of the hardware 
comprising a node. See also "the 
definition of a node. 



protocol 



remote node 



A formal set of conventions or rules 
governing the format and relative timing 
of message exchange. 



A node in a network 
local node. 



that is not your 



remote NSP 
remote task 
server task 

source node 
source task 



NSP executing in a remote node. 

A task executing in a remote node. 

An alternate designation for a task that 
has declared itself willing to accept a 
network connection, usually to provide 
some system service. 

The node at which the request for a 
connection is initiated or from which a 
message is transmitted. 

The task in which the request for a 
connection is initiated or from which a 
message is transmitted. 
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synchronous transmission 



target node 



target task 



TKB20 



Transmission in which time intervals 
between transmitted characters are of 
equal length. Multiple characters can 
be transmitted without start or stop 
bits following an initial synchronizing 
sequence. 

The node at which the request for a 
connection is accepted or rejected or to 
which a message is transmitted. 

Any task that has declared itself 
willing to accept a network connection. 

TKB20 is the program that constructs 
PDP-11 formatted task images from object 
files during the configuration procedure 
for a DECnet node. 



UETP 



up-line dumping 



UETP is the acronym for User Environment 
Test Package. UETP is a collection of 
programs, data files, and batch control 
files designed to allow the user to 
verify the integrity of the operating 
system. UETP acts as an interface 
between the user and the batch system by 
allowing the user to selectively access, 
enable, and run tests in the form of 
batch control files. In this manual, 
UETP is used during the installation, 
verification, and certification 
procedures. 

Transmitting a copy of a computer's 
memory over a logical link and storing 
it in a file on another node. 



verification procedure 



The DECnet verification procedure 
ensures that the appropriate DECnet-20 
software modules have been installed. 
The verification process checks for the 
existence of each required module and 
for the correct version of each required 
module . 



VNP20 



VNP20 is the program that creates the 
communication front end system image 
during the configuration procedure for a 
DECnet node. 
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APPENDIX F 
SAMPLE PROGRAMS FOR REMOTE LOGIN 



F.l INTRODUCTION 

This appendix describes a set of three programs that use DECnet-20 
task-to-task communications capabilities to allow a terminal at a 
local host to log in to a remote host. The two environmental 
requirements for running these programs are that a DECnet connection 
must exist between the two hosts and that both hosts must be running 
the TOPS-20 operating system at or above Release 3A level. 

The three programs that implement the remote login function are NRT20, 
STNRT, and NKTSRV. The function of each program is defined briefly 
below: 



NRT20 



NRTSRV 



STNRT 



provides a network source task at the source 
terminal's local node, accepts data from the 
terminal, sends the data to the remote host via a 
network connection, and passes output from the 
remote host to the source terminal. 

provides a server task at the remote host to 
accept the network connection from NRT20, passes 
the received data to a pseudo-TTY, and returns 
output from the remote host to the network 
connection. The output is read by NRT20 and sent 
to the source terminal. 

creates a job that runs NRTSRV on the remote host. 



F.2 NRT20 PROGRAM 

NRT20 allows a user at a terminal on a TOPS-20 system to log in to a 
remote host in a DECnet network. Note that the type of operating 
system on the remote host is immaterial to the NRT20 program. 
However, this appendix describes the use of NRT20 in conjunction with 
the NRTSRV program which sets up a server task on a TOPS-20 host. 

NRT20 defines a network source task and establishes a task-to-task 
network connection between the source task and a previously defined 
target task at the remote host. NRT20 passes source terminal input to 
the network connection and passes the remote host's output to the 
source terminal. The program also provides for a special escape 
character by which the user can exit normally from NRT20 and return to 
TOPS-20 (EXEC) command level at the local node. Finally, NRT20 
monitors the network connection and handles any unexpected break in 
the connection. 
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The NRT20 source listing provided in this appendix contains code that 
implements the functions described immediately below. The order in 
which the functions are coded in the listing parallels the order in 
which the functions are presented in this description. 



F.2.1 NRT20 Initialization Routines 

NRT20 performs the following actions to create the proper environment 
for executing its major functions: 

• Creates an inferior process to read input from the source 
terminal and to send the source terminal's input to the remote 
host. 

• Enables the job to trap ~C interrupts and send the ~C 
characters to the remote host. 

• Initializes, activates, and enables the software interrupt 
system to handle input of a special escape character from the 
terminal. This permits the user to exit from the remote host 
and return to EXEC level at the local node. 

• Permits the user to define the special escape character either 
by default or by explicit specification. This action occurs 
as part of the initial NRT20-user dialogue, as shown in 
Section F.6 "Using the Remote Login Capability". 

• Disables echoing and sets binary data mode for the terminal. 
This is done so that the monitor at the remote host can assume 
responsibility for echoing and character handling and 
translation for the terminal. 

• Opens a network connection to the server task at the remote 
host. NRT20 uses the file specification: 

DCN:node-200 

where node is the remote host's node name as specified by the 
user in the NRT20-user dialogue and 200 is the object type for 
the server task NRTSRV. If the object type 200 is already in 
use, another object type should be selected instead. (Refer 
to Appendix B for a list of available object types.) If 
another object type is selected, the user must modify both the 
DCN: specification in the NRT20 program and the SRV: 
specification in the NRTSRV program. 



F.2.2 NRT20 Operations 

NRT20 handles data transmission between the terminal and the remote 
host by performing the following actions: 

• Starts an inferior process that reads terminal input and sends 
the input to the remote host. The inferior process sends all 
characters (except the special escape sequence) to the remote 
host and passes all data received from the remote host to the 
terminal . 
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• If the network connection is broken unexpectedly, NRT20 prints 
the following message: 

PConnection broken. Reason: nn: reasontext 

where nn is the DECnet disconnect reason code and reasontext 
is the explanation for the disconnect. Following the printing 
of the message, NRT20 returns to EXEC command level. If the 
user enters CONTINUE at this point, NRT20 restarts processing 
from the beginning, as though the user had entered NRT20 in 
response to the @ monitor prompt. 

• When the user enters the special escape sequence, NRT20 
freezes the inferior process and prints 

[Connection broken, back at node node-name, 
Type CONTINUE to resume connection] 

where node-name is the node name of the local node to which 
the terminal is attached. NRT20 returns to EXEC level where 
the user may resume NRT20 processing at the point of the 
interrupt by entering CONTINUE. If the user enters CONTINUE, 
NRT20 prints: 

%Reconnecting to remote node... 

and unfreezes the inferior process. At that point, the user 
is connected to the remote system and processing is resumed. 
(Section F.6.3 contains an example of this situation.) 



F.3 STNRT PROGRAM 

The server task NRTSRV permits remote users to log in to the host on 
which NRTSRV is running. For security reasons, NRTSRV must not be run 
from a logged in job. If NRTSRV were run from a logged in job, any 
user could log in to NRTSRV with the same user name and privileges as 
specified for the job under which NRTSRV is running without supplying 
a password. The use of the program STNRT prevents such a potential 
breach of system security. 

STNRT creates a job with the following characteristics: 

• The job is not logged in. 

• The job has the file SYS:NRTSRV.EXE as its top-level process. 

• The job is not owned by the user running STNRT. 

STNRT must be included in the PTYCON.ATO file to initialize the NRTSRV 
program at system startup time. (Inclusion of the STNRT job in the 
PTYCON file is described in Section F.5 "Installation", below.) At 
system initialization time, STNRT creates a job with the 
characteristics described above and also: 

• Starts the job. 

• Detaches the job. 

• Halts execution and returns to EXEC. 
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F.4 NRTSRV PROGRAM 

NRTSRV is a server task that allows users at remote terminals to log 
in to the system on which NRTSRV is running. The number of users that 
may run concurrently under NRTSRV is set by using the MAXFRK parameter 
in the NRTSRV. MAC source file. 

NRTSRV implements remote logins by connecting to pseudo-terminals on 
its local host. Therefore, the maximum number of users cannot exceed 
the number of pseudo-terminals on the host on which NRTSRV is running. 
Before setting the value of MAXFRK, the user should take into 
consideration other processes that require the use of PTYs, such as 
BATCH and PTYCON. Other factors that affect the maximum number of 
users of the remote login capability are the maximum number of forks 
permitted by the remote system and the system manager's evaluation of 
the demand for the remote login capability. The value of MAXFRK is 
set to 7 on the distribution tape. 

When NRTSRV receives a network connection, it opens a pseudo-terminal 
(PTY) . As NRT20 sends messages over the network connection to NRTSRV, 
NRTSRV passes the messages to the PTY. Conversely, as NRTSRV s host 
system sends messages to the PTY, NRTSRV passes the messages over the 
network connection to NRT20. 

The NRTSRV source listing provided in this appendix contains code that 
implements the functions described immediately below. The order in 
which the functions are coded in the listing parallels the order in 
which the functions are presented in this description. 



F.4.1 NRTSRV Initialization Routines 

NRTSRV performs the following actions to create the proper environment 
for executing its major functions: 

• Sets the private name of the program being run by the job set 
up by STNRT to NRTSRV. 

• Verifies that the DECnet server device SRV: exists on the 
system. If SRV: does not exist on the system, the job is 
logged out. 

• Enables the system-permitted capabilities for the job. 

• Creates and starts n inferior processes, each of which is a 
copy of NRTSRV. 

• Disables the system-permitted capabilities for the top-level 
process. 

• Sets up a routine to handle the abnormal termination of any 
inferior process. 

The job capabilities are originally enabled for the top-level process 
so that they may be passed on to the inferior processes. The NRTSRV 
program ensures that no logins occur between the time that the 
capabilites are enabled for the top-level process and the time that 
they are disabled after having been passed on to the inferior 
processes. A login during that time could constitute a breach of 
system security. 
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There are two situations in which NRTSRV must guard against undesired 
logins: (1) during the time that the job capabilities are originally 
passed on to the inferior processes and (2) during the time that a new 
inferior process is created to replace an inferior process that 
terminated abnormally. In both cases, NRTSRV prohibits logins by 
freezing the inferior processes until the job capabilties have been 
passed on. 

If you intend to modify the NRTSRV source for your system, it is 
recommended that you preserve this "no login" feature. 



F.4.2 NRTSRV Operations 

NRTSRV accepts input from the terminals and transmits PTY outputs in 
the manner described below: 

• Each inferior process performs the following actions: 

Clears, then sets up and initializes the software 

interrupt system. 

Removes any PTY or server JFN assignments. 

Opens a DECnet server connection with the filespec 

SRV:200 which specifies a DECnet generic server with 

object type 200. 

Assigns and enables software interrupt channels tor 

connect event notification and data available events for 

the server JFN. 

Awaits a software interrupt signalling an incoming 

connection. 

When the inferior process receives a connect request, it 
requests a PTY to be used to log in the remote terminal. If a 
PTY is not available, the inferior process sends the following 
message to NRT20 to be printed at the user's terminal: 

?No more PTYs on remote host 

Processing is then restarted as described above for inferior 
processes. If a PTY connection is available, the NRTSRV 
inferior process does the following: 

Issues a *C to the PTY. The system then issues its 

standard banner message. 

Accepts the connection from the network and sets up a 

routine run at background level to read data from the PTY 

and pass it down the network logical link to the NRT20 

program. 

When a network connection data available is signalled, 

the inferior process reads the data and passes it to the 

PTY 
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Data processing continues until the link is broken. When the 
link is broken, processing is restarted as described above for 
inferior processes. 

• In the event of an abnormal termination of an inferior 
process, NRTSRV 

Freezes all inferior processes. 

Scans to identify the inferior process that terminated. 

Kills the inferior process. 

Creates and starts another inferior process. 

Resumes all inferior processes. 



F.5 INSTALLATION PROCEDURES 

The programs required to implement the remote login capability are 
included on the distribution tape as part of the release of TOPS-20 
Version 4. The following files are relevant: 

CMD.UNV STNRT.REL 

CMD.REL STNRT.EXE 

NRT20.MAC STNRT.LST 

NRT20.REL NRTSRV. MAC 

NRT20.EXE NRTSRV. REL 

NRT20.LST NRTSRV.EXE 

NRT20.MAC NRTSRV. LST 

CMD.UNV and CMD.REL are associated with the NRT20 files and are 
relevant only if modifications to the NRT20.MAC source code are 
contemplated. 

Installation of the remote login capability involves two steps: 
restoring the necessary executable files from the distribution tape 
and modifying the PTYCON.ATO file on each host on which NRTSRV is to 
run to automatically start NRTSRV at system initialization time. 



F.5.1 Restoring Files from the Distribution Tape 

Follow the steps below to restore the required files from the 
distribution tape: 

1. Log in as OPERATOR (or as any user with wheel or operator 
privileges) and enable capabilities. 

2. Connect to the directory in which your installation's 
unsupported software is maintained. (The directory should be 
in the system search list SYS:.) For example: 

$connect ps : <unsuppor ted>(jiLL) 

connects to the directory PS: <UNSUPPORTED> which contains the 
system's unsupported software. You should replace 
PS:<UNSUPPORTED> with the name of the directory that 
maintains your installation's unsupported software. 

3. Mount the distribution tape and run DUMPER to restore the 
following executable files: NRT20.EXE, NRTSRV.EXE, and 
STNRT.EXE. Also, you may optionally restore any other 
supporting files that you want for your installation. 
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F.5.2 Editing the PTYCON.ATO File 

Prior to using the remote login capability, you must edit your 
installation's PYTCON.ATO file which is processed at system start-up 
time. Add a line to run the STNRT program at a convenient place in 
one of the operator jobs running under PTYCON. For example, the 
following sequence shows the editing of a PTYCON.ATO file. The 
operator edits the file to insert the STNRT command immediately above 
the PUSH command. 

$type ptycon. ato ( ret ) 

SILENCE 

LOG 

DEFINE ~$OPR 

CONN OPR 

LOG OPERATOR FOO OPERATOR 

ENA 

!NEW OPERATOR INTERFACE PARSER 

OPR 

TAKE SYSTEMrNCP.CMD 

TAKE SYSTEM:DN200.CMD 

PUSH 

ENA 

~ESET LOGIN ANY 

~ESEND * SYSTEM IN OPERATION 

APPEND PS:<SPOOL>ORION-SYSTEM-LOG.002.* PS : <SPOOL>ORION-OLD. LOG 

DELETE PS : <SPOOL>ORION-SYSTEM-LOG .002.* 

POP 

~X 

NO SILENCE 

W ALL 

CONN OPR 



$edit pytcon.atoQIf 

Edit: PTYCON.ATO. 1 

*fPUSH$~:*QID 

01100 PUSH 

*i.-lG»D 

01050 STNRTQID 

*eu ( ret ) 

[PTYCON.ATO. 2] 
$ 



F.6 USING THE REMOTE LOGIN CAPABILITY 

Each time the system is brought up, the edited PTYCON.ATO file runs 
the STNRT program. STNRT loads, starts, and then detaches the server 
task NRTSRV which automatically sets up the inferior processes that 
wait for a connection request from a remote terminal. Users at remote 
terminals may then run NRT20 to access the host on which NRTSRV is 
running . 
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F.6.1 Logging in to a Remote Host Using NRT20 

You invoke NRT20 by entering some form of the NRT20 command in 
response to the TOPS-20 prompt at your terminal. NRT20 expects you to 
specify the remote host's node-name and a special escape character to 
be used to exit from NRT20. If you do not specify a special escape 
character, NRT20 uses ~Y by default. 

To specify the remote host's node-name and use ~Y as the special 
escape character, use the following NRT20 command format: 



@NRT20 node -name ( ret ) 

NRT20 sets ~Y as the special escape character and prints the following 
message : 

[Type ~Y to return to node node-name] 

where node-name is the name of the terminal's local host. If you 
enter an invalid node name (or if no physical connection exists) , 
NRT20 prints: 

Connection broken. Reason: 39: Network failure. No path to 
remote node. 

and terminates processing. You are returned to EXEC command level. 

To specify a different special escape character, use one of the 
following NRT20 command formats: 



@R NRT20GiD 
or 

@NRT20QID 

NRT20 then prompts for the special escape character: 

Escape character (~Y) : 

Press the control key and enter any ASCII character between A and Z 
except for the following system-recognized control characters: ~C, 
"F, ~G, "I, "J, ~M, "0, "0, ~R, ~S, "T, ~U, and ~W. In addition, if 
you have enabled any other control characters, they are also invalid 
as the special escape character for NRT20. If you enter a carriage 
return, NRT20 uses ~Y as the special escape sequence. 

If you did not enter a node name, as shown in the two NRT20 command 
lines above, NRT20 prompts you for one as follows: 

Host name: 

Enter the remote host's node name. If you enter a carriage return, 
NRT20 reissues the prompt until you enter a valid node name or a ~C. 
If you enter an invalid node name, NRT20 responds in the manner 
previously described by printing an error message and terminating 
processing. 
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After a successful connection to the remote host, NRT20 prints the 

remote host's standard banner message on your terminal. After the 

banner message is printed, you may perform any function permitted by 
the remote host. 



F.6.2 Exiting from a Remote Host Using NRT20 

To exit normally from the remote host, type the special escape 
sequence selected (or defaulted) in the initial NRT20 dialogue. (See 
Section F.2.2 for NRT20's response and your possible actions when an 
abnormal disconnection occurs.) When you enter the special escape 
sequence, NRT20 prints the following message on your terminal: 

[Connection broken, back at node node-name, 
Type CONTINUE to resume connection.] 

You may continue NRT20 execution from the point of the interrupt by 
entering the CONTINUE command. NRT20 responds: 

%Reconnecting to remote node... 

At this point, the connection is restored and the terminal is again 
connected to the remote host. 



NOTE 

It is strongly recommended that you log 
off the remote system before breaking 
the network connection between the local 
system and the remote system. If you do 
not log off before breaking the 
connection, the job will exist on the 
remote system in a DETACHED state and 
may require operator intervention to 
kill it. 



F.6.3 Sample Terminal Sessions Using NRT20 

Note that, when used within the context of the remote login 
capability, ~S, and ~Q do not stop the scrolling of pages on the 
user's terminal. This occurs because NRT20 does not trap these 
control characters and also because one cannot use the TERMINAL PAGE 
command to set the printing mode of a PTY. 
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Example 1. 

The following example shows user KAMANITZ at a terminal on system 
2102. He first logs in to 2102, then uses NRT20 to connect to the 
remote system 4097. By entering the remote system's node name on the 
NRT20 command line, KAMANITZ allows NRT20 to use ~Y as the special 
escape character. He then logs in to system 4097 as user CRUGNOLA, 
performs functions on system 4097, and logs off 4097. After logging 
off of system 4097, he presses ~Y to return to system 2102. From 
2102, he issues a LOGOUT command to log off system 2102. 

2102 Development System, TOPS-20 Monitor 4(3117) 
@LOGIN KAMANITZ password 341QJD 

Job 16 on TTY106 19-Sep-79 14:41:15 
@NRT20 4097QID 
[Type ~Y to return to node 2102] 

4097 Load-Test System, TOPS-20 Monitor 4(3100) 
@LOGIN CRUGNOLA password 34l f^D 
Job 12 on TTY50 19-Sep-79 14:41:27 

. (User performs functions on system 4097.) 

@LOGOQet3 

KILLED JOB 12, USER CRUGNOLA, ACCOUNT 341, TTY 50, 
AT 19-SEP-79 14:41:49, USED 0:00:02 IN 0:00:21 

(User enters ~Y here which is not echoed.) 

[Connection broken, back at node 2102, 
Type CONT INUE to resume connection] 

@LOGOQeT) 

KILLED JOB 16, USER KAMANITZ, ACCOUNT 341, TTY 106, 
AT 19-SEP-79 14:46:53, USED 0:00:01 IN 0:05:37 
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Example 2. 

In the following example, user KAMANITZ logs in to system 2102. Then, 
he uses NRT20 to connect to system 4097 and specifies ~B as the 
special escape character. Once he is connected to 4097, he logs on as 
user CRUGNOLA and begins listing his directory. While system 4097 is 
printing information about his directory, he presses ~B to gain the 
attention of NRT20 on system 2102. From 2102, he enters CONTINUE in 
response to the EXEC prompt and NRT20 reconnects to system 4097. 
System 4097 resumes printing information about his directory. (Note 
that the directory listing does not contain the lines that would have 
printed during the time used to escape from and return to system 
4097.) User KAMANITZ then logs off system 4097, returns to system 
2102, and logs off system 2102. 

2102 Development System, TOPS-20 Monitor 4(3117) 
@LOGIN KAMANITZ password 341QED 

Job 62 on TTY106 19-Sep-79 14:50:59 
@NRT2 ( Kbi ) 

Escape character (~Y) :( cim7 ) 
Host name : 409 7CEED 

4097 Load-Test System, TOPS-20 Monitor 4(3100) 
@LOGIN CRUGNOLA password 341QID 
JOB 13 ON TTY50 19-Sep-79 14:53:09 

evnTRr^FP) 

PS:<CRUGNOLA> 

CALEND.EXE.1;P777700 5 (User enters CTRL/B. It does not 

echo. ) 

[Connection broken, back at node 2102, 

Type CONTINUE to resume connection] 

@CONTINUEQir) 

Reconnecting to node... 

10-6-AUG-79 15:51:41 

LA36.CMD. 1;P777700 1 74(7) 13-MAR-78 15:39:48 

LOGIN.CMD. 2;P777700 1 21(7) 13-MAR-78 15:36:23 

MAIL. TXT. 1;P770404 1 175(7) 26-JUL-79 13:01:46 

SWITCH. INI;2;P777700 1 39(7) 18-MAY-78 15:33:10 

VT50.CMD;1;P777700 1 28(7) 13-MAR-78 15:37:44 

VT52.CMD. 1;P777700 1 60(7) 13-MAR-78 15:38:49 

ZIP.Q;1;P777700 1 45(7) 14-JUN-78 17:06:25 

total of 13 pages in 9 files 
@ logo Gil) 

killed job 13, user crugnola, account 341, tty 50 
at 19-sep-79 14:55:45, used 0:00:03 in 0:02:36 

(User enters CTRL/B. It does not echo.) 

[Connection broken, back at node 2102, 
Type CONT INUE to resume connection] 

@LOGOQtT) 

KILLED JOB 62, USER KAMANITZ, ACCOUNT 341, TTY 106, 
AT 19-SEP-79 14:56:53, USED 0:00:01 IN 0:05:37 



F-ll 



SAMPLE PROGRAMS FOR REMOTE LOGIN 



Example 3. 

This example shows the use of NRT20 to log in to a remote host that is 
not an adjacent node in the network. The network is configured 
according to the following diagram: 



I HOST ! 
! 2102 ! 



i i 

i HOST ! 

! 4097 i 

t i 



HOST I 
2137 ! 



User CRUGNOLA on host 4097 wants to log in to host 2137. To do so, he 
first logs in to host 4097. Then, he uses NRT20 to establish a 
network connection to host 2102 using the default special escape 
character. Once the connection to host 2102 is established, user 
CRUGNOLA logs in to host 2102 as user KAMANITZ. From host 2102, 
KAMANITZ uses NRT20 to establish a network connection to host 2137, 
specifying ~B as the special escape character. 

Note that a different special escape character must be used for the 
connection between hosts 2102 and 2137. If the same special escape 
character were used for both network connections, NRT20 on 4097 would 
trap the special escape character and return control of the user's 
terminal to host 4097. This would interrupt the connection between 
hosts 4097 and 2102. Once this occurred, no means would exist to gain 
access to host 2102 on the existing connection. 
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After the network connection is established between hosts 2102 and 
2137, user KAMANITZ logs in to host 2137 as user OSMAN. OSMAN 
performs some functions on host 2137, then logs off and enters ~B to 
return to host 2102. Once at host 2102, user KAMANITZ logs off and 
enters ~Y to return to host 4097. Once there, user CRUGNOLA logs off. 

4097 Load-Test System, TOPS-20 Monitor 4(3100) 
@LOG CRUGNOLA password 34l C^D 

Job 7 on TTY33 25-Sep-79 10:18:05 
@NRT20 2102Q1D 
[TYPE ~Y TO RETURN TO NODE 4097] 

2102 Development System, TOPS-20 Monitor 4(3117) 

LOG KAMANITZ password 34l C^D 

Job 42 on TTY217 25-Sep-79 10:19:17 
@NRT20 CUD 

Escape character (~Y) : (ctrub) 
Host name : 2137(~re7 



Gus - The Language s Sy stem (2137), TOPS-20 Monitor 4(3046) 

@LOG OSMAN passwordQID 
Job 20 on TTY214 25-Sep-79 10:20:58 

(User performs functions on host 2137) 

§ LOGO CUD 

Killed Job 20, User OSMAN, Account MONITOR, TTY 214 
at 25-Sep-79 10:21:30, Used 0:00:02 in 0:00:31 

(User enters CTRL/B. It does not echo.) 

[Connection broken, back at node 2102, 
Type CONT INUE to resume connection] 
PLOGOC^D 

Killed Job 42, User KAMANITZ, Account 341, TTY 217 
at 25-Sep-79 10:23:18, Used 00:00:01 in 0:05:00 

(User enters CTRL/Y. It does not echo.) 

[Connection broken, back at node 4097, 
Type CONT INUE to resume connection] 
@LOGOQeD 

Killed Job 7, User CRUGNOLA, Account 341, TTY 33, 
at 25-Sep-79 10:26:31, Used 0:00:08 in 0:07:26 
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TITLE NRT20 - Program to permit logins to remote network host 



COPYRIGHT (C) 1979 BY 

DIGITAL EQUIPMENT CORPORATION, MAYNARD , MASS. 

THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED 
ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE 
INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER 
COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY 
OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY 
TRANSFERRED. 

THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE 
AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT 
CORPORATION. 

DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS 
SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL. 

SALL ; Keep listing uncluttered, no macro expansion 

SEARCH MONSYM,MACSYM,CMD ; Universals to search 

•REQUIRE SYS:MACREL,SYS:CMD ; Make LINK load these automatically 

SUBTTL DECLARED SYMBOLS 

Tl==l ; AC definitions 

T2 = = 2 

T3= = 3 

T4 = = 4 

CX==16 

P==17 



NPDL==20 
INSIZ==50 
MAXINP==INSIZ*5 
DBUFFR==100000 



Size of pushdown list 
Terminal input buffer size, in words 
Maximum number of terminal input characters 
Data buffer on page 100 
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SUETTL IMPURE STORAGE 



STIMSK: 


BLOCK 


1 


LOCAL: 


BLOCK 


2 


DCNJFN: 


BLOCK 


1 


INSTR: 


BLOCK 


INSIZ 


SAVACE: 


BLOCK 


4 


NAME : 


BLOCK 


10 


FORK: 


BLOCK 


1 


VIRGIN: 


EXP -1 


PC: 


BLOCK 


3 


LEVTAB: 


PC 

PC + 1 
PC + 2 




CHNTAB: 









1, ,ESC 









PDL: 


BLOCK 


NPDL 


CMDSTG 







Terminal interrupt word mask for STIW 

Local node name 

JFN of logical link to NRTSRV server 

Terminal input stream buffer 

Register save area for AC ' s 1-4 

File spec name of logical link to NRTSRV 

Handle of inferior process to read from TTY 

Flag to indicate fresh start, initially -1. 

Storage for PC on interrupts 

Software interrupt level table 



; Software interrupt channel table 

; Panic character (default ~Y) 

; Pushdown list (STACK) 

; Command parser storage (from CMDS) 
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SUBTTL START - Start of NRT20 program 



START: RESET 

MOVE P,[IOWD NPDL,PDL] 

AOS VIRGIN 

CALL CMDINI 

MOVX T1,CR%MAP 

SETZM T2 

CFORK 

JRST [ JSHLT 

JP.ST START] 
MOVEM Tl,FORK 
MOVEI Tl,.FHSLF 
RPCAP 

TXO T3,SC%CTC 
EPCAP 

MOVE T2, [LEVTAB, ,CHNTAB] 
SIP 

MOVX T2,1B1 
AIC 
EIR 

CALL ALLON 
CALL PRESCN 

JRST PREHST 
JRST ESCHAR 



Intialize ourself 

and set up pushdown list 

Bump count of times we come through here 

Initialize command parser 

Create process to read from TTY 

Make the process, same address map 

; on error... halt and allow continue 

Save the process handle obtained 
Our process handle 
Get our capabilities 
allow ~C trapping for job 
Enable new set of capabilities 
; Address of software interrupt system tables 
Give them to monitor 
Channel number 

Activate software interrupt channels 
Enable software interrupt system 
Turn on all TTY interrupts 
Prescan EXEC line for host name... 
Got it - skip the prompting 
Otherwise get it now 
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SUETTL ESCHAR - Obtain the escape character user wants to use 



ESCHAR: PROMPT <Escape char ac ter ( " Y) : > ; Put out prompt to users terminal 

MOVEI T1,[FLDDB. ( . CMTXT , CM%SDH , , <Cha r ac ter for interrupting connect ion> ,<~ Y>) 
CALL CFIELD ; Read the escape character 

LDB Tl, [POINT 7,ATMBUF,6] ; Get character itself 
CAILE T1,.TICCZ ; Is it a valid character? ("A to ~Z) 

JRST [ HRROI T1,[ASCIZ /Invalid character/] ; No, tell user 
ESOUT 

and try again 

Save the character 

Character value is terminal code 

Channel number 

Assign terminal code to software interrupt channel 

Get a bit 

Make terminal interrupt word mask for character 

Allow typein 

Save for use later 

Get the host name 



JRST ESCHAR] 
MOVNI T2,0(T1) 
HRLS Tl 
HRRI Tl,l 
ATI 

MOVX T1,1B0 
LSH T1,0 (T2) 
TXO Tl, 1B<.TICTI> 
MOVEM T1,STIMSK 
JRST HSTNAM 
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SUBTTL HSTNAM - Get the host name user wants to login on 



HSTNAM: PROMPT <Host name: > 
PREHST: MOVEI T1,[FLDDB. (.CMTXT 
CALL CFIELD 
HRROI T1,INSTR 
HRROI T2,ATMBUF 
MOVEI T3,0 
SOUT 

MOVX T1,177B6 
TDNN Tl, INSTR 
JRST [ HRROI Tl, [ASCIZ / 
[CONNECTING TO LOCAL HOST- /] 

PSOUT 

MOVEI T1,.NDGLN 

MOVEI T2,T3 

HRROI T3, INSTR 

NODE 

HRROI Tl, INSTR 

PSOUT 

HRROI Tl, [ASCIZ /] 



/: 



PSOUT 
JRST .+1] 
JRST SETTMD 



Put out prompt to users terminal 
CM%SDH, , <Name of system to connect to>) ] 
Read host name 

Pointer to destination buffer 
Pointer to source buffer 
An ASCIZ string 
Copy the host name 
See if real host name given 
Was one? 

; No, tell user what's happening 

; Function code to get local node name 

; Obtain local node name 
; Output to user's TTY 

; Finish the message nicely 
Have name. Now set TTY modes 
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SUBTTL SETTMD - Set TTY modes 



SETTMD: MOVEI T1,.PRIIN 
RFMOD 

TXO T2,TT%WAK 
TXZ T2,TT%ECO!TT%DAM 
SFMOD 

MOVX Tl, .FHJOB 
MOVE T2,STIMSK 
STIW 

HRROI T1,NAME 
HRROI T2,[ASCIZ /DCN: 



/] 



SETZM 


T3 


SOUT 




HRROI 


T2,INSTR 


SOUT 




HRROI 


T2, [ASCIZ 


SOUT 




MOVX T1,GJ%SHT 


HRROI 


T2,NAME 


GTJFN 




JRST 


[ JSERR 



Primary input 

Get current JFN mode word 

Wake on all 

Echoes off and binary data mode 

Set new JFN mode word 

Set terminal interrupt word for entire job 

Get terminal interrupt word saved earlier 

Set it to allow only panic interrupts 

Build network file spec to NRTSRV 

The DECnet device for making connection 



The node name to connect to 



/-200/] ; NRTSRV s object type 



CALL ALLON 
JRST HSTNAM] 

MOVEM T1,DCNJFN 

MOVEI Tl, .PRIOU 

GDSTS 

ERJMP [SETZM T2 

JRST .+1] 

MOVE T1,DCNJFN 

TXNE T2,GD%PAR 

S K I P A T 2 , 



I r UU ( DO ,Ut %bb2 
BSZ) 



MOVE T2, [FLD("D7,OF% 
OPENF 
JRST [ JSERR 

MOVE T1,DCNJFN 

RLJFN 
JFCL 

CALL ALLON 

JRST HSTNAM] 
MOVE Tl,FORK 
MOVEI T2,DOINP0 
SFORK 
ERJMP [RESET 

JSHLT 

JRST START] 
JRST GOTDA1 



Do 
Us 
Ge 



Sa 
Ch 
Ge 



; Re 
; Do 

) lOJr 
!OF% 
: Od 



a short form GTJFN 
ing the spec just built 
t DCN connection 

If error , tell user 
Reset TTY to normal mode 
And go back to get host name 
ve JFN for the connection 
eck if parity OK on this TTY 
t device status 

; If error, set all status off 
; And continue along 
store the JFN for network connection 
es terminal allow parity? 

*RUIOF%WRJ ; Yes, 8 bit bytes and read/write access 
RD!OF%WR] ; No, then 7 bit bytes and read/write access 
en the network connection 
; If failed, tell user 
; And release the JFN 



; Reset TTY to normal mode 
; And go back to get host name 
Restore the process handle obtained 
The start address 

Start the process to read input from TTY 
If failed, reset ourself 
Tell user and halt 

Go back to beginning if continued 
Connection now opened. Wait for input 
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SUBTTL GOTDA1 - Read data from network connection 



GOTDA1: MOVE Tl,DCNJFN ; Get the network connection JFN 

MOVE T2, [POINT ~D8,DBUFFR] ; Pointer to buffer 



MOVNI T3,l 
SIN 

ERJMP BADCON 
MOVE T3,T2 
SIBE 

SKIPA 
JRST [ SETZM T4 

JRST GOTDAX] 
EXCH T2,T3 
MOVE T4,T3 
MOVNS T3 
SIN 

ERJMP BADCON 



One byte only 

Read from logical link 

; If error, connection broken 
Save byte pointer 
Any more data to read now ? 

; Yes, read the rest 
No, then go type what there is to user 

Restore byte pointer 

Save count 

Read the exact number available 

Read remaining bytes 

; If error, connection broken 



GOTDAX: MOVEI Tl,.PRIOU 

MOVE T2, [POINT ~D8,DBUFFR] 

MOVNI T3,1(T4) 

SOUT 

JRST GOTDA1 



Output to users terminal 

; Pointer to data from remote host 
Output count 

Type data on users terminal 
And continue 
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SUBTTL ALLON - Restore echoing and interrupts on terminal 



ALLON: MOVX T1,.FHJ0B 
SETOM T2 
STIW 

MOVEI Tl , .PPIIN 
RFMOD 

TXC T2,TT%ECO!TT%DAM 
SFMOD 
RET 



Set terminal interrupt word for entire job 

Terminal interrupt word mask for all codes 

Set terminal interrupt word 

Primary input 

Read JFN mode word 

Echo on, ASCII data mode, output translation disabled 

Set new JFN mode word 

Done, return to caller 
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SUBTTL PRESCN - Prescan EXEC command for host name 



PRESCN: 


SKIPE 
RETSKP 


VIRGIN ; 




MOVEI 


T1,.RSINI 




RSCAN 






ERJMP 


PRESC1 




MOVX 


T1,.RSCNT ; 




RSCAN 


/ 




ERJMP 


PRESC1 




JUMPE 


Tl, [RETSKP] ; 




MOVEI 


T1,.PRIIN ; 




BIN 






CAIE 


T2,"R" '; 




CAIN 


T2,"r" 




JRST PRESCO ; 


PRES1: 


CAIE 


T2," " ; 




CAIN 


T2," " ; 




JRST 


PRES2 




CAIN 


T2,.CHLFD 




RETSKP 






BIN 






JRST 


PRES1 ; 


PRES2: 


MOVSI 


T1,.TICCY 




HRRI 


Tl, 1 ; 




ATI 






MOVX 


T1,1B0 ; 




LSH 


T1,-.TICCY ; 




TXO 


T1,1B<.TICTI> 




MOVEM 


T1,STIMSK 




TMSG 


< [Type ~Y to reti 




MOVX Tl, .NDGLN 



Starting out fresh? 

No..., so return +2 to force prompt 

Make rescan buffer available 

as command line to process reading from CTTY 

Get count of characters 
in rescan buffer 



None there, so must prompt 
Primary input 
Read a character 

RUN or R (program name can't start with "P"; 
Check lowercase also 

Yes, no prescanning, go eat rest of line 
Have we hit a space yet? 
Also accept a tab 
Yes, read the node name 
Have we hit EOL yet? 

Yes, no node name, skip return to prompt 
Read the next character 
And loop to test 

Default to ~Y for interrupt character 
And use channel one 

Assign terminal code to interrupt channel 
Get a hi order bit 
Shift bit by value of ~Y code 
Allow typein 
Save for use later 
turn to node > ; Tell user how to get back 



MOVX T2,T3 

MOVE T3, [POINT 7, LOCAL] 

NODE 

JFCL 
HRROI Tl, LOCAL 
PSOUT 
TMSG 



PROMPT 
RET 



< 



<> 



And name of local node 



Finish off nicely 

Null prompt 

Done, return no skip to not prompt 



;HERE TO FLUSH REST OF EXEC COMMAND LINE 



PRESCO: BIN 

CAIE T2, .CHLFD 
JRST PRESCO 
RETSKP 



Get next byte 

The end of line? 

No, Try again 

Yes, return +2 to prompt for node 



; Here if rescan attempt does not succeed 

PRESC1: HRROI Tl , [ ASCIZ/Unexpected error in scanning command line/]; If error, 



ESOUT 
HALTF 
JRST START 



tell user 

and halt 

Start over if continued. 
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SUBTTL BADCON - Handle a broken network connection 



BADCON: CIS 

CALL ALLON 

MOVE Tl,FORK 

KFORK 

HRROI Tl, [ASCIZ / 
PConnection broken. Reason: 

PSOUT 

MOVE T1,DCNJFN 

MOVEI T2,.MORLS 

MTOPR 

HRRZ T2,T3 

MOVEI Tl, .PRIOU 

MOVEI T3,12 

NOUT 
JFCL 

CAIG T2,MAXMSG 

SKIPN T1,MSGTBL(T2) 

SKIPA 

PSOUT 

HRROI Tl, [ASCIZ / 



/] 



PSOUT 

MOVE T1,DCNJFN 

TXO Tl,CZ%ABT 

CLOSF 

HALTF 

JRST START 



Prevent further interruption 
Restore TTY modes 
Restore the process handle 
Kill the terminal input process 



/] ; Tell user bad news 

; Restore network connection JFN 
; Get current link status 



Get DECnet error reason code 
Output to users terminal 
In decimal 
Type it 

Know about this error? 
Yes, have one to type? 

No 

Yes, type it then 



Pretty it 

Get the JFN for the link 

Abort any operations 

Close it 

Halt here 

And start at beginning if continued 
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SUBTTL ESC - Handle input of panic escape character from terminal 



; Save AC'S we're going to use 



Restore process handle 

Freeze the terminal input process 

Users terminal 

Get current TTY modes 

Save them 

ASCII data mode, output translation disabled 

Set new JFN mode word 

Flush any pending terminal output 



ESC: DMOVEM Tl,SAVACE 

DMOVEM T3,SAVACE+2 

MOVE T1,F0RK 

FFORK 

MOVEI Tl,.PRIOU 

RFMOD 

PUSH P,T2 

TXO T2,TT%DAM 

SFMOD 

CFOBF 

HRROI Tl, [ASCIZ / 
[Connection broken, back at node /] ; Tell user he's now talking to us 

PSOUT 

MOVX Tl, .NDGLN 

MOVX T2,T3 

MOVE T3, [POINT 7, LOCAL] 

NODE ; Get our node name 

JFCL 

HRROI Tl, LOCAL 

PSOUT ; Type node name to user 

HRROI Tl, [ASCIZ/, 
Type CONTINUE to resume connection] 
/] ; Let him know how to restart 

PSOUT 

HALTF ; Halt here until continued 

HRROI Tl, [ASCIZ/%Reconnecting to remote node... 
/] ; Let user know we are restarting 

PSOUT 

MOVEI Tl, .PRIOU 

POP P,T2 

SFMOD 

MOVE Tl,FORK 

RFORK 

DMOVE T1,SAVACE 

DMOVE T3,SAVACE+2 

DEBRK 



Users terminal 

Desired TTY modes 

Set new JFN mode word 

Restore process handle 

Resume the terminal input process 

Restore the AC ' s 

; And finish interrupt processing 
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SUBTTL DOINPO - Read terminal input and send to remote host 



DOINPO: MOVEI T4,MAXINP 

MOVE T3, [POINT 7,INSTR] 

MOVEI Tl,.PRIIN 

BIN 

JRST DOINO 

DOINP: SIBE 

SKIPA 

JRST EMPTY 

BIN 
DOINO: IDPB T2,T3 

SOJG T4, DOINP 
EMPTY: MOVNI T3,MAXINP 

ADD T3,T4 

JUMPE T3, DOINPO 

MOVE T1,DCNJFN 

HRROI T2,INSTR 

SOUTR 

JRST DOINPO 



Maximum input characters 

Where they are going 

Primary input 

Wait for a byte 

Got one, go handle it... 

Any bytes? 

Yes 

No 

Get another byte 

Stash it in input stream buffer 

Do it all 

Maximum characters 

Compute number to send 

If none, go wait 

The network JFN 

Pointer to input stream buffer 

Send this buffer to remote NRTSRV 

And continue 
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SUBTTL MSGTBL - Table of DECnet disconnect/abort reason text 



MSGTBL: 



-1,,[ASCIZ /: Destination node does not exist/] 



-1,,[ASCIZ /: Destination process does not exist/] 









-1,,[ASCIZ /: Connection aborted by remote node/] 

BLOCK ~D22 

-1,,[ASCIZ /: No more NRTs at remote node/] 

-1,,[ASCIZ /: No more NRTs at remote node/] 

BLOCK 4 

-1,,[ASCIZ /: Remote process aborted link/] 

-1,,[ASCIZ /: Network failure. No path to remote node/] 
MAXMSG== . -MSGTBL-1 

END START 
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TITLE NRTSRV - Program to provide remote network login service 



COPYRIGHT (C) 1979 BY 

DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS, 



THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED 
ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE 
INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER 
COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY 
OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY 
TRANSFERRED. 



THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE 
AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT 
CORPORATION. 



DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY 
SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL. 



OF ITS 



SALL 

SEARCH MONSYM,MACSYM 

.RFOriTRR .SYR rMACRFT. 



Keep listing uncluttered, no macro expansion 
Universals to search 

Makf* LINK 1 narl fh^SP snfnmat i^al lv 



SUBTTL DECLARED SYMBOLS 



Tl = = l 
T2 = = 2 
T3 = = 3 
T4 = = 4 
CX==16 
P= = 17 



AC definitions 



MAXFRK==7 

SRVOSZ==50 

MAXOUT==SRVOSZ*4 

SRVSIZ==10 

NPDL==40 



Maximum number of server sub processes 
Output buffer size in words 
Maximum number of output characters 
Size of server buffer in words 
Size of pushdown list 



F-27 



SAMPLE PROGRAMS FOR REMOTE LOGIN 



SUBTTL IMPURE STORAGE 



SAVAC : 

DEVNAM: 

PTYJFN: 

TTYJFN: 

SRVJFN: 

SRVINP: 

OUTPUT: 

OUCNT: 

PC: 

SRVOUP: 

FORKS: 

HSTNAM: 

PDL: 



BLOCK 4 

BLOCK 2 

BLOCK 1 

BLOCK 1 

BLOCK 1 

BLOCK SRVSIZ 

BLOCK 1 

BLOCK 1 

BLOCK 1 

BLOCK SRVOSZ 

BLOCK MAXFRK 

BLOCK 2 

BLOCK NPDL 



AC save area 

For building PTY names 

The JFN of the PTY 

TTY designator 

The JFN of the network connection 

Holds input characters 

Output buffer pointer 

The software interrupt PC save area 
Holds output data 
Save process ID's here 
Host name string 
Pushdown list (stack) 



RELOC 1000-140 



Start on page boundary 



LEVTAB: 
CHNTAB: 



PC 

1, ,GOTCI 

1, ,GOTDAT 



Where to stash the PC 

Network connect received interrupt routine 

Network data available interrupt routine 
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SUBTTL BEGIN - Start of NRTSRV program 



BEGIN: RESET 

MOVE T1,[SIXBIT /NRTSRV/] 

SETNM 

HRROI T1,[ASCIZ /SRV/] 

STDEV 
JRST [ SETOM Tl 
LGOUT 
JFCL 
HALTF] 

MOVEI Tl, .FHSLF 

RPCAP 

MOVE T3,T2 

EPCAP 

MOVSI T4,-MAXFRK 
FRKDO: MOVX Tl,CR%CAP 

SETZM T2 

CFORK 
ERJMP WTFRK 

MOVEM Tl,FORKS(T4) 

HRLZ T2,Tl 

HRRI T2,l 

MOVE Tl, [.FHSLF, ,1] 

MOVEI T3,ENDPRG-1 

LSH T3,-ll 

TXO T3,PM%CNT!PM%RD!PM%WR 

PMAP 

HLRZ T1,T2 

MOVEI T2, START 

SFORK 
FRKLOP: AOBJN T4, FRKDO 
WTFRK: MOVEI Tl,. FHSLF 

SETZM T3 

EPCAP 

MOVEI Tl, .FHINF 

RFORK 

WFORK 



Initialize ourselves 

; Our name in SIXBIT 

Set jobs private name 

See if network exists 

By checking for SRV device 

Doesn't exist, so go away 
By logging out this job 
Should always work, but... 
Either way, go away 

This process 

Get our capabilities 

Copy them 

Enable all capabilities we have 

Maximum processes to create 

Give them the same capabilities we have 

No AC's 

Create a process 

; If no more, done 

Save process handle 

Process handle of destination 

Start at page 1 in destination process 

Map this process to it 

Last address in use 

Make a repetition count 

; Make PMAP argument 

Map the process' address space 

Get process handle 

Start address 

Start the process up 

Do all of them 

Our process 

No capabilities 

Disable all capabilities 

All the inferior processes 

Resume them 

Wait for any inferior to halt 
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SUBTTL RSPROC - Restart inferior process after it halted 



RSPROC: MOVEI T1,.FHINF 

FFORK 

MOVSI T4,-MAXFRK 
DEDLOP: SKIPN Tl, FORKS (T4) 

JRST DEDLOl 

RFSTS 

LOAD T1,RF%STS,T1 

CAIE Tl, .RFHLT 

CAIN Tl,.RFFPT 

JRST [ MOVE Tl, FORKS (T4) 
SETZM FORKS (T4) 
KFORK 
HRRZS T4 
MOVEI T1,.FHSLF 
RPCAP 

MOVE T3,T2 
EPCAP 

JRST FRKDO] 
DEDLOl: AOBJN T4, DEDLOP ; 

JRST WTFRK ; 



All the inferior processes 

Freeze them 

Scan process table 

This one exist? 

No, go on 

Yes, get its status 

Get its status 

Halted? 

Or error? 

Yes, get process handle again 

Clear entry 

Kill the process 

Create one more process 

Our process 

Get our capabilities 

Copy them 

Enable all capabilities we have 

Go back and create another process 
Look at them all 
Wait some more 
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SUBTTL START - Start of code for inferior process' 



START: CIS 

SKIPN T1,SRVJFN 

JRST START1 

TXO T1,CZ%ABT 

CLOSF 
JFCL 

SETZM SRVJFN 
START1: SKIPN T1,PTYJFN 

JRST START2 

TXO T1,CZ%ABT 

CLOSF 
JFCL 
START2: MOVE P,[IOWD NPDL,PDL] 

MOVEI T1,.FHSLF 

MOVE T2, [LEVTAB, ,CHNTAB] 

SIR 

MOVX T2,3B1 

AIC 

EIR 



Clear interrupt system 

Have a server JFN yet? 

No. . . 

Yes, abort it 

Close and abort the network connection 

; Ignore errors 
Clear the server JFN 
Have a PTY yet? 
No. . . 

Yes, abort it 
Close the PTY 

; Ignore errors 
Initialize the stack pointer 
Our process 

; Address of level and channel table 
Set software interrupt table addresses 
Channel and 1 

Activate software interrupt channels 
Enable software interrupt system 



MOVE Tl, [POINT 

MOVEM Tl, OUTPUT 

MOVEI T1,MAX0UT 

MOVEM Tl,OUCNT ; 

MOVEI T1,.FHSLF 

RPCAP 

MOVE T3,T2 

EPCAP 

MOVX T1,GJ%SHT 

HRROI T2,(ASCIZ /SRV:200/] 



D8,SRV0UP] ; Initial output pointer 
; Initialize the pointer 
; Maximum output characters 
; Initialize the output count 
; Our process 
; Get our capabilities 
; Copy them 

; Enable all capabilities we have 
; Short form GTJFN 

The NRT server file spec 
Get 



GTJFN ; Get a JFN for it 

JRST TRYAGN ; Failed, go try to recover 

MOVEM Tl, SRVJFN ; Save the server JFN 

MOVX T2,<FLD{~D8,OF%BSZ) !OF%RD!OF%WR> ; 8 bit bytes, read/write access 
OPENF ; Open the server JFN 

JRST [ MOVE Tl, SRVJFN ; Failed, get server JFN 

Release the JFN 
Ignore errors 
Clear the server JFN 
And go try to recover 
Our process 
No capabilities 
Disable all capabilities 
Get the server JFN 

Assign interrupt system channel numbers 
MOVX T3 r - <FLD{0,MO%CDN) !FLD(l,MO%DAV) !FLD(.MOCIA,MO%INA) > ; Connect event on 

; Data available on 1 
MTOPR ; Perform the device operation 

WAIT ; Wait for something to happen 



[ MOVE Tl, SRVJFN 
RLJFN 
JFCL 
SETZM SRVJFN 
JRST TRYAGN] 

MOVEI T1,.FHSLF 

SETZB T2,T3 

EPCAP 

MOVE Tl, SRVJFN 

MOVEI T2,.MOACN 
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SUBTTL TRYAGN - Wait before trying to become a server again 



TRYAGN: MOVX Tl , ~D< 1000* 60* 2> 
DISMS 
JRST START 



Two minutes in milliseconds 

Dismiss the process until time expires 

And go back to try again 
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SUBTTL GOTCI - Got a connect from the network 



GOTCI: CALL GETPTY 
JRST [ CIS 

HRROI Tl, [ASCIZ 
?No more PTYs on remote host 

/] 

MOVE T2,SRVJFN 

SETZM T3 

SOUTR 
ERJMP .+1 

MOVE T1,SRVJFN 

CLOSF 
JRST START 

SETZM SRVJFN 

JRST START] 
MOVEM T1,PTYJFN 
MOVEM T2,TTYJFN 
MOVEI T2,"C"-100 
BOUT 

MOVE Tl, SRVJFN 
MOVEI T2, .MOCC 
SETZB T3,T4 
MTOPR 

ERJMP START 
MOVEI T1,PTYIN 
MOVEM T1,PC 
GJINF 

JUMPL T4,DONCI 
HRROI Tl, [ASCIZ / 
NRTSRV- CONNECTION FROM /] 
PSOUT 

SETZM HSTNAM 
MOVE Tl, SRVJFN 
MOVEI T2,.MORHN 
HRROI T3, HSTNAM 
MTOPR 

ERJMP .+1 
HRROI Tl, HSTNAM 
PSOUT 

HRROI Tl, [ASCIZ / ON /] 
PSOUT 

MOVEI Tl,.PRIOU 
MOVE T2,PTYJFN 
SETZM T3 
JFNS 
HRROI Tl, [ASCIZ / 

/] 

PSOUT 
DONCI: DEBRK 



Get a PTY to use 

; Failed, clear the software interrupt system 

Point to message to tell what happened 

Get the server JFN 

All of the string 

Send message on network link 

Ignore errors 

Get the server JFN 

Close the network connection 

; Failed, go back to recover 
; Clear the server JFN 
; Go back to recover 
Save the PTY JFN 
Save the TTY designator 
Get a Control-C (~C) 
Output it to PTY to start up job 
Get the server JFN 
Confirm the network connection 
No optional data 
Do the device operation 

; If error, link broken, start again 
Address of PTY input routine 
Change the interrupt PC value to start 
Get current job information 
If terminal attached to job, done 

Point to message to say who's connecting 

Output to TTY 

Clear host name buffer 

Get the server JFN 

Read network host name 

Pointer to buffer 

Do the device operation 

; Ignore errors 
Pointer to host name buffer 
Output the host name to TTY 
Pointer to continuation of message text 
Output to TTY 
TTY designator 
Get the PTY JFN 

Full file specification format 
Output file spec associated with PTY JFN 



; End the message nicely 

; Dismiss interrupt and resume processing PTY input 
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SUBTTL GOTDAT - Got data available from network connection 



GOTDAT: DMOVEM Tl,SAVAC 

DMOVEM T3,SAVAC+2 
GOTDA1: MOVE Tl,SRVJFN 

MOVEI T2, .MORLS 

MTOPR 

TXNN T3,MO%CON 

JRST START 

SIBE 
SKIPA 

JRST [ DMOVE T1,SAVAC 

DMOVE T3,SAVAC+2 
DEBRK] 

CAILE T2,SRVSIZ*5 

MOVEI T2,SRVSIZ*5 

MOVN T3,T2 

MOVE T4,T3 

HRROI T2,SRVINP 

SIN 
ERJMP START 

SUB T4,T3 

MOVE T3,T4 

MOVE T1,PTYJFN 

HRROI T2,SRVINP 

SOUT 

JRST GOTDA1 



Save AC ' s 

Get the server JFN 

Read link's status 

Do the device operation 

Connected? 

No, go start over 

Skip if input buffer empty 

Not empty, have some data 

; Empty, no data, restore AC ' s 

; Dismiss interrupt and resume processing 
Buffer larger than number of bytes available? 
No, get maximum buffer full 
Get byte count 
Save it 

Pointer to server input buffer 
Read from network link 

; Failed, link broken, start again 
Calculate number of bytes read 
Get byte count 
Get PTY JFN 

Pointer to server input buffer 
Output data to PTY 
And go back to do more 
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SUBTTL PTYIN - Pseudo TTY input routine 



PTYIN: MOVE T1,PTYJFN 
BIN 

IDPB T2, OUTPUT 
SOSG OUCNT 
JRST PTYIN1 
MOVE T1,TTYJFN 
SOBE 
JRST PTYIN 

PTYIN1: MOVNI T3,MAXOUT 
ADD T3, OUCNT 
MOVE T1,SRVJFN 
MOVE T2, [POINT " 
SOUTR 

ERJMP START 
MOVE Tl, [POINT ' 
MOVEM Tl, OUTPUT 
MOVEI T2,MAXOUT 
MOVEM T2,OUCNT 
JRST PTYIN 



D8,SRVOUP] 



D8,SRVOUP 



Get PTY JFN 

Input a byte from PTY 

Store byte in output buffer and save pointer 

Output buffer full? 

Yes, write it then 

Get TTY designator 

Skip if TTY output buffer empty 

; Not empty, go get more characters from PTY 
Get negative maximum output count 
Compute number of bytes in buffer 
Get the server JFN 

; Get pointer to output buffer 
Output data to network link 

; Failed, link died, start over 

; Get pointer to output buffer 
Reinitialize output buffer pointer 
Get maximum output count 
Reinitialize output count 
Go back and get more characters from PTY 
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SUBTTL GETPTY - Get a pseudo TTY designator and return opened PTY JFN 



GETPTY: STKVAR <SAVCHR> ; 

MOVE T1,[SIXBIT /PTYPAR/] 

SYSGT 

HRRZM T1,SAVCHR 

HLRZ T4,T1 

MOVNS T4 

HRLZS T4 
GETPT1: MOVSI Tl , . DVDES+. DVPTY 

HRR T1,T4 

DVCHR 

TXNN T2,1B5 

JRST GETPT2 

MOVE T2,T1 

HRROI T1,DEVNAM 

DEVST 
JRST GETPT2 

MOVEI T2," : " 

IDPB T2,T1 

SETZM T2 

IDPB T2,T1 

MOVX T1,GJ%SHT 

HRROI T2,DEVNAM 

GTJFN 
JRST GETPT2 

MOVE T3,T1 

MCVX T2,<FLD(~D8,OF%BSZ) ! 

OPENF ; 

JRST [ MOVE T1,T3 
RLJFN 
JFCL 
JRST GETPT2] 

MOVEI T2, .TTDES(T4) 

ADD T2,SAVCHR 

RETSKP 



Get stack variable storage 

; Pseudo TTY parameter table name 

Get system table information for PTY 

Save TTY number of first pseudo TTY 

Get number of PTY ' s 

Get negative of count 

Make an index loop pointer 

Get device designator for PTY 

Get PTY number 

Get device characteristics of PTY 

Available? 

No, try next PTY then 

Get device designator 

Pointer to device name string buffer 

Translate device designator to string 

; Failed, try next PTY 
Get device string terminator character 
Store it after device name string 
Get a null byte 
Make device name string ASCIZ 
Short form GTJFN 
Get pointer to PTY name string 
Get a JFN for PTY 

; Failed, try next PTY 
Save the PTY JFN 
OF%RD!OF%WR> ; 8 bit bytes, read/write access 
Open the PTY 

; Failed, get PTY JFN 

; Release the PTY JFN 

; Ignore errors 

; And try next PTY 
Get PTY index 
Get PTY designator 
Done, return skip for success 



; Step through all PTY ' s 



GETPT2: AOBJN T4,GETPT1 
RET 



Increment PTY number and go back if more to do 
No, give up, return no skip for failure 



ENDPRG: 



END BEGIN 



End of code 
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TITLE STNRT - Program to create NRTSRV as a not logged in job 



COPYRIGHT (C) 1979 BY 

DIGITAL EQUIPMENT CORPORATION, MAYNARD , MASS 



THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED 
ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE 
INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER 
COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY 
OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY 
TRANSFERRED. 



THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE 
AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT 
CORPORATION. 

DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS 
SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL. 



SALL 

SEARCH MONSYM,MACSYM 

.REQUIRE SYS:MACREL 



Keep listing uncluttered, no macro expansion 

Universals to search 

Make LINK load these automatically 



SUBxTL DtC^AKED bYMbOLb 



Tl = = l 
T2 = = 2 
P= = 17 



; AC definitions 



NPDL==10 



; Size of pushdown list 
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SUBTTL IMPURE STORAGE 



PDL: 



BLOCK NPDL 



Pushdown list (stack) 



CRJBLK 



Argument block for CRJOB JSYS 
No user name string 
No password string 
No account string 



-1,,[ASCIZ /SYS:NRTSRV.EXE/] ; Pointer to file name to be placed in job 





377777 

















Entry vector offset 

Controlling terminal designator is null device 

(Reserved) 

Address of AC block 

Command language processor flags 

Primary I/O designators for inferior processes 

CPU runtime limit (0 = no limit) 

Capability mask for job 

IPCF PID for logout message 
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SUBTTL START - Start of program 

START: RESET ; Initialize ourself 

MOVE P,[IOWD NPDL,PDL] ; Initialize PDL pointer 
MOVX Tl,CJ%FIL!CJ%NPW!CJ%CAP ; CRJOB flags 

MOVEI T2,CRJBLK ; Address of argument block 

CRJOB ; Create the job 
JSHLT ; Failed 

HALTF ; Made it 

END START 
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APPENDIX G 
TKB20 AND VNP20 WARNING AND ERROR MESSAGES 



This appendix contains a list of messages that may be directed to the 
user's I/O device by TKB20 and/or VNP20. The messages are separated 
into two groups: warning messages and fatal error messages. Within 
each group, the messages are listed in alphabetical order. 

Each warning message is preceded by a percent sign (%). TKB20 or 
VNP20 issues a warning message to indicate a possible problem. 
Processing continues; however, subsequent processing may or may not 
be successful. If processing terminates some time after a warning 
message is issued, the user should be aware of any prior warning 
messages. The problem highlighted in the prior warning message may be 
related to the termination of processing. 

Fatal error messages are characterized in two ways: a fatal error 
message may be preceded by a question mark (?) or it may have no 
leading punctuation mark at all. After a fatal error message has been 
issued by TKB20 or VNP20, processing is always terminated. The user 
should then call his local Software Support Specialist, unless the 
corrective action is apparent from the message text. 

Replaceable arguments in both warning and fatal error messages are 
shown as abbreviations. The following abbreviations are found in 
several messages: 



Abbreviation 

addr 

cmdline 

cntname 

ddmname 

dlcname 

fn 

ft 

llcname 

modname 

objf ile 

psect 

rtnname 

symname 



Meaning 

octal address 

command line 

controller name 

device driver module name 

data link controller name 

file name 

file type 

logical link controller name 

module name 

object file name 

p-section name 

routine name (usually follows the 

message text and two dashes) 

symbol name 



Certain messages contain replaceable arguments that are relevant only 
to the message containing the replaceable argument. In these cases, 
the replaceable arguments are defined immediately following the 
message text. 
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G.l TKB20 AND VNP20 WARNING MESSAGES 

% Badly formatted OBJ file objfile — rtnname 

% Checksum error in OBJ file objfile; should be mmm, was 
nnn — rtnname 

mmm is the octal value of the computed checksum. 

nnn is the octal value of the checksum that was read. 

% Divide by zero when resolving relocation in P-section 
psect — rtnname 

% Global symbol symname defined in module modi with value xxx and in 
mod2 with value yyy 

modi is the name of the first module. 

xxx is the value of the first symbol. 

mod2 is the name of the second module, 

yyy is the value of the second symbol. 

% Global symbol symname is not defined in fn — rtnname 

% Global symbol symname is undefined 

% Module modname multiply defines P-section psect; flags = xxx, were 
yyy - rtnname 

xxx is the octal value of the new flags, 

yyy is the octal value of the old flags. 

% Object file feature is unsupported — rtnname 

% Only one module allowed in symbol table file fn — rtnname 

% Partition length of mmm less than task length of nnn — rtnname 

mmm is the partition length in octal, 

nnn is the task length in octal. 

% Relocation value xxx truncated to 8 bits in P-section 
psect — rtnname 

xxx is the octal value that was truncated. 

% Unspecified output file: "fn", ignored - rtnname 



G.2 TKB20 AND VNP20 FATAL ERROR MESSAGES 

Some fatal error messages may be issued by more than one routine or 

module. These messages are identified in this appendix by the 

"rtnname" replaceable argument following the message text. Other 
fatal error messages are issued by only one routine from a specific 

module. In this latter type of fatal error message, the actual 

routine name is shown at the end of the message text. 
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Each fatal error message beginning with ? is followed by the message: 

PTerminating - No recovery Available for Previous Error. 
ADDRESS OUT OF RANGE - GET11 
ADDRESS OUT OF RANGE - STOll 

Attempting to OPEN an already OPEN channel - OPEN 
BACKSLASH MISSING - VRBL_SYM 
BAD PSECT POINTER - PRC_RELOC 
BAD PSECT POINTER - STO_TEXT 
CALL TO GETSTG BEFORE INISTG 
? Cannot find nnn bytes in system pool in fn — rtnname 

nnn is the number of decimal bytes requested. 

Channel is not OPEN - CLOSE 
Channel is not OPEN - INPUT 
Channel number out of range - INPUT 
Channel number out of range - OUTPUT 
? Complex relocation exceeded stack limit of nnn, file fn — rtnname 

nnn is the stack limit in decimal. 

? DCP dlcname is unknown — rtnname 

? DDM ddmname is unknown — rtnname 

EOF IGNORED IN SCAN 

? Error in text file fn — rtnname 

? Failure freeing nnn bytes at addr in system pool in fn, code 
errcode — rtnname 

nnn is the number of octal bytes in the block in 

question, 
errcode is the decimal error code. 

? File fn size of xxx bytes is larger than max of yyy - rtnname 

xxx is the file's size in decimal. 

yyy is the maximum permissible file size in decimal. 

? Illegal error 

This message indicates that the error number is out of the range of 

the defined error numbers. The "Terminating " message does not 

follow this message, as it does for all other error messages 
preceded by a question mark. 

? Indirect files nested too deep: "cmdline" — rtnname 

? Input error or unexpected EOF — rtnname 
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? Invalid address addr in file fn — rtnname 

? Invalid Address Match for KDPLN For CNT$DF xxx — D_KDP 

xxx is a controller number. 

? Invalid Address Match Starting KDZLN For CNT$DF xxx — D_KDZ 

xxx is a controller number. 

? Invalid CNT$DF for DDM ddmname — LD_DDM 

Invalid Channel Number - CLOSE 

Invalid Channel Number - OPEN 

? Invalid contype - xxx found — rtnname 

contype is the type of construct that was found to be 

invalid. 
xxx is the decimal value of the invalid construct. 

? Invalid error 

This message indicates that the error message has no text. 
? Invalid file name: "fn" — rtnname 

? Invalid Interrupt Setup for driver in file fn — LOADD 
? Invalid UNT$DF for DDM ddmname and CNT$DF cntname — LD_DDM 
? I/O DATA ERROR on fn, status = stat — rtnname 

stat is the octal status of the I/O data error. 

? LLC llcname is unknown — rtnname 

LLC NOT FOUND - LD_LLC 

? Loading library file libname overflowed network pool by nnn 
bytes — rtnname 

nnn is the decimal number of bytes that overflowed the 

pool . 

? LOOKUP/ENTER UUO failed for fn, code = errcode — rtnname 

errcode is the octal error code. 

May not OPEN channel - OPEN 

MISSING CONTROLLER - LD_DLC 

MISSING SLT - D_DCP 

NO DEVICE COO: - MOUACP 

NO DEVICE LB - INSTALL 

NO GEN PARTITION - INSTALL 

? No input files — rtnname 
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? OPEN UUO failed for filename — rtnname 

? Program logical address space (PLAS) is not supported — rtnname 

NOT ENOUGH STORAGE FOR INITIALIZATION - INISTG 

? Second ft file in command string: "fn" — rtnname 

? Storage exhausted — rtnname 

? Switches must be associated with a file — rtnname 

? Symbol symname has conflicting values in symtabl and 
symtab2 -- rtnname 

symtabl is the first symbol table file. 
symtab2 is the second symbol table file. 

? Syntax error in command line: "cmdline" — rtnname 

TCB LINKS BAD - INSTALL 

? The Communications Executive has already been loaded into 
kernfile — rtnname 

kernflle is the name of the kernel file 

? The top of the COMM EXEC is too high: ceaddr .GT. maxaddr in 
fn — rtnname 

ceaddr is the address of the top of the communications 

executive . 
maxaddr is the maximum permitted address of the RSX11S 

executive . 

UNIT MISSING - LD_DLC 

You May Not Close Channel - CLOSE 

? 22-bit memory management not supported in fn - rtnname 
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32KBLD.CMD file, 

use of defined, 9-4 



4-CONFIG.CMD file, 10-1, 
10-6, 10-12, 10-26, 
10-30, 10-33, 10-45, 
10-46 



Aborting a network 
connection, 5-2 

notification of, 5-2 

reason code, 5-2 
Acceptance tests, 10-20 

defined, E-l 
Accepting a connection, 

3-23 
Access information switches, 
8-7 

/ACCOUNT, 8-7 

/PASSWORD, 8-7 

/USER, 8-7 
Accessible nodes, 

listing, 7-2 
Accessing a remote node, 

conditions for, 6-2 
Accessing files, 

on remote hosts, 8-1 
Account string, 

readinq the, 3-18 
/ACCOUNT" switch, 8-7 
/ASCII switch, 8-7 
Asynchronous transmission, 

defined, E-l 
Automatic reload of DN20, 

6-17 
Automatic startup, 

DECSYSTEM-2020, 6-4 

DECSYSTEM-2040/50/60, 6-7 



Batch file, 

for remote node, 8-15 
BATCH log file, 10-18 
Bibliography, D-l 
BIN monitor call, 2-5, 4-3 
BOOT monitor call, 2-5, 2-6 

functions, 2-6 
Bootstrapping, 

-2040/50/60, 6-13 

specifying secondary load 
file, 6-13 



Bootstrapping (Cont.) 

specifying tertiary load 

file, 6-13 
BOUT monitor call, 2-5, 4-2 
BRIEF.TXT file, 10-20, 

10-55 
.BTBEL function of BOOT, 

2-6 
.BTCHN function of BOOT, 

2-6 
.BTCLI function of BOOT, 

2-6 
.BTCPN function of BOOT, 

2-6 
.BTDMP function of BOOT, 

2-6 
.BTIPR function of BOOT, 

2-6 
.BTKMD function of BOOT, 

2-6 
.BTKML function of BOOT, 

2-6 
.BTLDS function of BOOT, 

2-6 
.BTRDD function of BOOT, 

2-6 
.BTRLC function of BOOT, 

2-6 
.BTRMP function of BOOT, 

2-6 
.BTROM function of BOOT, 

2-6 
.BTSDD function of BOOT, 

2-6 
.BTSLS function of BOOT, 

2-6 
.BTSMP function of BOOT, 

2-6 
.BTSSP function of BOOT, 

2-6 
.BTSTA function of BOOT, 

2-6 
.BTSTP function of BOOT, 

2-6 
.BTSTS function of BOOT, 

2-6 
. BTTPR function of BOOT, 

2-6 
BUGCHK, 

in SYSERR file, C-l 
BUGINF, 

in SYSERR file, C-l 
BUILD-ALL. CTL file, 
defined, 9-4 
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Card reader , 

certifying, 10-52 

in configuration, 9-7 
CCB, 

in configuration, 9-8 
Certification procedure, 

defined, E-l 
Certifying DECnet-20, 10-20 

DN200, 10-51 

error/event logging test, 
10-54 

flowchart, 10-23 

line loopback test, 10-35 

list of directories for, 
10-20 

list of files for, 10-20 

loopback, 10-21 

NFT test, 10-48 

Remote-NCP test, 10-40 
CETAB, 

defined, 9-5 
Changing output destination, 

7-3, 7-4 
Changing the network, 

procedure, 9-3 
Changing the node name, 

9-16 
Changing the node number, 

9-16 
CHARS.TXT file, 10-20 
CHK11, 

SYSERR entry for, C-8 
Clearing interrupts, 3-11 
CLOSF, 

with CZ%ABT, 5-3 
CLOSF monitor call, 2-5, 
5-2, 5-7 

example, 5-2, 5-5 

with CZ%ABT, 5-7 
Closing a logical link, 5-2 
Closing a network 
connection, 5-1 

NSP control, 5-1 
Closing a network JFN, 5-3 
Coding examples, 

source task, 5-5 

target task, 5-6, 5-7 
COMIOP.KMC file, 6-10 
COMIOP.KMC program, 6-20 
Command file, 

executing, 8-15 

passwords omitted, 8-15 
Command files, 

for NCP commands, 6-24 
Communications front end, 
1-2 

auomatic dump of, 6-18 

displaying line 
statistics, 6-20 



Communications front end 

(Cont. ) 

dumping the, 6-19 

error/event logging, 6-24 

loading, 6-13 

logging activity, 6-15 

reload, 6-16 
Communications line 
controller , 

dumping a, 6-21 

loading a, 6-20 
Computer network, 

defined, E-l 
Configuration , 

defined, E-l 
Configuration tools, 9-1 

defined, 9-4, E-l 
Configuring DECnet-20, 

adjusting hardware 
parameters, 9-18 

building DN20, 9-15 

building RJE , 9-23 

changing software 
parameters, 9-19 

creating system image, 
9-22 

directories, 9-10 

identifying dn20, 9-16 

overview, 9-2 

restoring files, 9-12 

saving configuration, 
9-21 

terms defined, 9-6 

work space for, 9-1 
Connect , 

defined, E-l 
Connect confirm message, 
3-23 

explicit, 3-23 

implicit, 3-23 
Connect event interrupt, 

3-11 
Connect initiate message, 

3-1 
Connect password, 

defined, E-l 
Connect reject message, 

explicit, 3-23 

implicit, 3-24 

reading data in, 3-19 

reject code, 3-24 
Connection , 

establishing a, 3-1 
Console front end, 1-2 
Controlling error/event 

logging, 6-24 
COPY (NFT command) , 8-6 

switches, 8-7 
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Creating a logical link, 

example, 5-5 
Cyclic redundancy check, 

1-3 
CZ%ABT flag bit for CLOSF, 

5-2 



DAP protocol, 1-6, 8-1 

defined, E-2 

reference document, D-l 
Data, 

segmentation of, 4-1 

sending, 4-1 
Data available interrupt, 

3-11 
Data transfer in general, 

1-3 
Data transfers, 

continuous stream, 4-1 

general, 4-1 

ioyical messages, 4-1 
Data transmission, 

defined, E-2 
Date/time , 

displaying, 6-23 
DCN: , 

network device, 2-1, 3-1 
DCN: device, 

attributes, 3-6 

descriptor, 3-5 

file specification, 3-5 

hostname field, 3-5 

objected, 3-5 

task name, 3-5 
.DCXO disconnect code, A-l 
.DCX1 disconnect code, A-l 
.DCX11 disconnect code, A-l 
.DCX2 disconnect code, A-l 
.DCX21 disconnect code, A-l 
.DCX22 disconnect code, A-l 
.DCX3 disconnect code, A-l 
.DCX32 disconnect code, A-l 
.DCX33 disconnect code, A-l 
.DCX34 disconnect code, A-l 
.DCX35 disconnect code, A-l 
•DCX36 disconnect code, A-l 
•DCX37 disconnect code, A-l 
.DCX38 disconnect code, A-l 
.DCX39 disconnect code, A-l 
.DCX4 disconnect code, A-l 
.DCX40 disconnect code, A-l 
.DCX41 disconnect code, A-l 
•DCX42 disconnect code, A-l 
.DCX43 disconnect code, A-l 
.DCX5 disconnect code, A-l 
.DCX6 disconnect code, A-l 
.DCX7 disconnect code, A-l 



.DCX8 disconnect code, 

.DCX9 disconnect code, 

DDCMP, 1-3, 4-1 

data transfer functi 

4-1, 4-2 
defined, E-2 
error/event logging, 
initializing, 6-21, 
terminating, 6-22 

DDCMP protocol, 

reference document, 

DEBRK monitor call, 5- 
example, 5-6 

DECnet, 

object types, B-l 

DECnet commands, 
generic, 1-6 
TOPS-20-specif ic, 1- 

DECnet-20, 

and terminal users, 
capabilities, 1-4 
certification proced 

10-20 
configuration 

prerequisites, 9-1 
configuration tools, 
control , 1-5 
hardware, 9-7 
installing, 10-1 
monitor calls, 2-4 
operator interface, 
options, 1-1 
programmer interface 
protocols, 1-1 
software, 1-1 
structure, 1-2 
user interface, 1-6 
verification procedu 
10-12 

DECnet-20 concepts, 2- 
network an I/O devic 

2-1 
network JFNs, 2-3 
task a file, 2-1 

DECnet-20 restrictions 
displaying line 

statistics, 6-20 
displaying line stat 

6-23 
loading a node, 6-18 
protocol type, 6-15 

DECNET.DAT file, 10-20 

DECSYSTEM-2020, 

automatic startup, 6 
dumpinq a line contr 

6-2l" 
lines supported, 1-1 
loading a line contr 
6-20~ 



A-l 
A-l 

ons , 



6-24 
6-22 



D-l 
6 



6 

7-1 
ure , 


9-1 

1-5 
, 1-5 

re, 

1 
e, 



us , 



-4 
oiler , 



oiler , 
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DECSYSTEM-2020 (Cont.) 
manual startup, 6-10 
NETCON functions, 6-3 
starting cable loopback, 

6-22 
starting controller 

loopback, 6-21 
structure, 1-2 
DECS YSTEM-2 04 0/50/60, 
automatic dump of DN20, 

6-18 
automatic reload of DN20, 

6-17 
automatic startup, 6-7 
defining protocol, 6-15 
displaying line 

statistics, 6-20 
dumping a node, 6-19 
line logging restrictions, 

6-15 
lines supported, 1-1 
loading a node, 6-18 
loopback testing, 6-22 
manual startup, 6-10 
NETCON functions, 6-4 
specifying default dump 

file, 6-14 
specifying default load 

file, 6-14 
starting event/error 

logging, 6-24 
stopping event/error 

logging, 6-24 
structure, 1-2 
Default host node, 
displaying , 6-23 
Defaults , 

automatic dump of DN20, 

6-18 
dump file for -2040/50/60, 

6-14 
executor node, 6-23 
file processing modes, 

8-10 
load file for -2040/50/60, 

6-14 
logging interval, 6-16 
logical node, 7-2 
task name, 3-15 
DELETE (NFT command) , 8-11 
Deleting files, 

on remote hosts, 8-1, 

8-11 
Demultiplexing, 2-3 
DESTINATION-NODE switch, 

7-4 
example, 7-4 

or>n"!7i tt mvm 

L/binlD^ J. /\ X 
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Digital Data Communications 
Message Protocol, See 
DDCMP 
Digital Network 

Architecture, See DNA 
DIRECTORY (NFT command), 

8-11 
DISABLE EVENT-LOGGING (NCP 

command) , 6-24 
Disabling line loopback 

mode, 6-17 
Disconnect , 

defined, E-2 
Disconnect codes, 
table of, A-l 
with MTOPR, 5-3 
Displaying date/time, 6-23 
Displaying default host 

node, 6-23 
Displaying executor node, 

6-23 
Displaying files, 

from remote node, 8-15 
Displaying line statistics, 

6-20 
Displaying line status, 

6-23 
Displaying NETCON request 

queue, 6-19 
Displaying node name, 6-23 
Displaying node number, 

6-23 
Displaying node status, 

6-23 
Displaying operating system, 

6-23 
Displaying software 

versions, 6-23 
Distribution tapes, 9-4 
DMC11, 

defined, E-2 
in configuration, 9-7 
DMC11 device, 

error/event logging, 6-24 
DN20, 

automatic dump of, 6-18 
defined, E-2 
displaying line 

statistics, 6-20 
dumping the, 6-19 
error/event logging, 6-24 
in configuration, 9-6 
loading, 6-18 
DN200, 

certification, 10-51 
configuration procedure, 

9-23 
conJuicj iiv " ** p *"* v-^^r-^T.T^Ko 
9-26 
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DN200 (Cont.) 

loading, 6- 
DN200.CMD fil 
DN200BLD.CMD 

use of defi 
DN20BLD.CMD f 

use of defi 
DNA, 1-1 
DNMAC, 

defined, E- 
DNMAC program 

defined, 9- 
DNV2FT.APP fi 
DNV2FT.LOG fi 
DNV2LL.CMP fi 
DNV2LN.CMP fi 
DNV2LN.LIN fi 
DNV2LN.LOG fi 
DNV2LN.N0D fi 
DNWAIT.EXE fi 
Down-line loa 

defined, E- 



13 










e, 10 


-1, 


10- 


-7 


file, 










ned , 


9- 


-4 






ile, 










ned , 


9- 


-4 







4 

le, 

le, 

le, 

le, 

le, 

le, 

le, 

le, 

ding , 

2 



0-20 
0-51 
0-21 
0-20 
0-36 
0-38 
0-35 
0-21 



defined, E-2 

error/event logg 

in configuration 

interface, 2-2 
DTEMPS.BIN file, 

10-7 
DTEMPS.BIN file, 

example, 6-13 
DTEMPT.BIN file, 

10-7 
DTEMPT.BIN file, 

example, 6-13 
DUMP CONTROLLER, 6 
Dump file, 

specifying defau 
DUMP NODE, 6-19 
Dumping a line con 

6-21 
Dumping a node, 6- 
Dumping nodes, 

specifying defau 
file, 6-14 
Dumping the DN20, 
DUP11, 

in configuration 
Duplex , 

defined, E-2 
DYNETS.EXE file, 1 



ing, 6 — ^.4 
, 9-7 

10-1, 10-4, 



10-1, 10-4, 

6-21 
It, 6-14 
troller , 
19 

It dump 
6-19 
, 9-7 

0-20 



ENABLE EVENT-LOGGING (NCP 

command) , 6-24 
Enabling for interrupts, 

3-10, 3-12 



Enabling line loopback mode, 

6-16 
Error and event logging 

test, 10-54 
Error messages, 

from OPR and ORION, 6-30 

list of NETCON, 6-29 

NFT, 8-16 

TKB20, G-l 

VNP20, G-l 
ERROR. SYS file, C-l 

line statistics in, 6-15 
Error/event logging, 

Controlling, 6-24 

controlling, 6-24 

controlling at line level, 
6-24 

controlling at NICE level, 
6-24 

described, C-l 

entries, C-l 

NICE task, 6-24 

oj - j. J r i a 

OLOL Lilly, U — ZL1 

Stopping, 6-24 
Error/event logging reports, 
print using SYSERR, 10-55 
Establishing a network 

connection, 3-1 
checking status, 3-13 
Estimated -pool -size , 

in configuration, 9-9 
Examples , 

aborting a logical link, 

5-3, 5-4 
automatic startup, 6-4, 

6-5, 6-6 

DECS YSTEM-2 04 0/50/60, 

6-8, 6-9 
CLOSF monitor call, 5-5 
connect confirm, 3-24 
COPY, 8-8 

CZ%ABT flag bit, 5-3 
DCN: specification, 3-8 
DEBRK monitor call, 5-6 
deleting remote files, 

8-1, 8-11 
DESTINATION-NODE switch, 

7-4 
DTEMPS.BIN file, 6-13 
DTEMPT.BIN file, 6-13 
enabling interrupts, 3-12 
EXIT (NFT command), 8-14 
GTJFN monitor call, 5-5 

5-6 
HELP (NFT command), 8-14 
INFORMATION (NFT command), 

8-6 
INFORMATION (TOPS -20 

command) , 7-2 
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Examples (Cont . ) 

listing remote directory, 

8-12 
LOCAL-NCP test, 10-31 
LOCAL-NCP.CMD file, 10-29 
manual startup -2020, 

6-10 
manual startup 

-2040/50/60, 6-10 
.MOACN function, 3-12, 

5-6 
.MOCC function, 3-24, 

5-6 
.MOCLZ, 3-25 
.MOCLZ function, 5-2 
.MORAC function, 3-18 
.MORCN function, 3-20 
.MORDA function, 3-19 
.MORHN function, 3-14 
.MORIM function, 4-5 
.MORLS function, 3-13, 

5-7 
.MOROD function, 3-21 
.MORPW function, 3-17 
.MORSS function, 3-22 
.MORTN function, 3-15 
.MORUS function, 3-16 
.MOSIM function, 4-4 
MTOPR monitor call, 3-12, 

3-13, 3-14, 3-19, 3-20, 

3-21, 3-22, 3-24, 4-5, 

5-5, 5-6 
NCP commands, 6-1, 6-3 
NETCON responses, 6-27 
network file 

specification, 3-8 
OPENF monitor call, 5-5, 

5-6 
OPR initialization 

failure, 6-32 
PLEASE, 7-3 
processing interrupts, 

5-7 
programming, 5-5, 5-6, 

5-7, F-l 

reading host name, 3-14 
reading logical link 

status, 3-13 
remote logins, F-10 
REMOTE-NCP.CMD, 10-44, 

10-46 
restarting NETCON, 6-25 
restarting ORION, 6-25 
SECDMC.SYS file, 6-13 
sending user data, 3-24, 

3-25 

SET DEFAULTS 8-4 8-5 
SET LOCATION, 7-3 



Examples (Cont . ) 

SHOW COUNTS, 6-3 

SHOW COUNTS response, 
6-20 

SHOW QUEUE response, 6-19 

SHOW STATUS, 6-1 

SIBE monitor call, 5-7 

SINR monitor call, 5-7 

source task, F-l 

source task coding, 5-4, 
5-5 

SOUTR monitor call, 5-5 

SRV: specification, 3-8 

target task, F-l 

target task coding, 5-6, 
5-7 

TERDMC.SYS file, 6-13 

using CZ%ABT, 5-7 

using MO%CDN, 3-12 

using MO%DAV, 3-12 

using MO%INA, 3-12 

using .MOACN, 3-12 

WAIT, 3-12, 5-6 
EXCEPT.LOG file, 10-18 
Executing command file, 

8-15 
Executor node, 

default, 6-23 

displaying, 6-23 

setting, 6-23 
EXIT (NFT command), 8-14 
Exiting , 

from NFT, 8-14 
Exiting from NCP, 6-20 



FAL object name, B-l 
FAL program, 8-1 

and DAP, 8-1 

defined, 8-1, E-2 

responsibilities of, 8-1 
File processing mode, 

for local source files, 
8-9 

for remote source files, 
8-9 
File processing modes (NFT) , 

default destination modes, 
8-10 

restrictions on, 8-10 
File specification, 

examples, 3-7 

field lengths, 3-4, 3-7 

general, 3-3 

network, 3-3 
Filespec format, 



systems, 8-2 
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/FIXED switch, 8-7 

Flowchart , 

certification, 10-23 
installation, 10-3 
verifying DECnet-20, 
10-14 

Full-duplex , 
defined, E-2 



Generic task identification, 

2-3 
Glossary, E-l 
GROUPS directory attribute, 

USER, 10-35 
GTJFN, 

file specification, 3-3 
GTJFN monitor call, 2-3, 
2-5, 3-1, 5-5 

example, 5-5, 5-6 

filespec, 3-3 

•F ^ v- r* •> i •, v ,- ^ 4--,,-. I, c C 

i-wi. owul^c t_ a o r\ , j~-j 

for target task, 5-6 



Half -duplex , 

defined, E-2 
Hardware error, 

DUP11 header, C-7 

SYSERR entry for, C-6 
Hardware errors, 

reporting, 6-24 
HELP (NFT command), 8-14 
Host computer, 

defined, E-2 
Host name, 

reading, 3-14 
Host node, 

displaying default, 6-23 



/IMAGE switch, 8-7 
INFORMATION command, 7-2 
INFORMATION (NFT command), 

8-5 
examples, 8-6 
Information switches, 

/ACCOUNT access, 8-7 
INFORMATION (TOPS-20 

command ) , 7-2 
Initializing DDCMP, 6-21, 

6-22 
INITIATE LOGGING 

LINE-COUNTERS, 6-15 
Installation certification, 

10-20 



Installation certif 


icat ion 


(Cont. ) 




flowchart, 10-23 




Installation proced 


ure , 


defined, E-3 




Installing DECnet-20, 10-1 


4-CONFIG.CMD, 10- 


1, 10-6, 


10-12 




DN200.CMD, 10-1, 


10-7 


DTEMPS.BIN, 10-1, 


10-4, 


10-7 




DTEMPT.BIN, 10-1, 


10-4, 


10-7 




flowchart, 10-3 




NCP.CMD file, 10- 


1, 10-6, 


10-7 




nodename.SYS, 10- 


4 


nodename.SYS file 


, 10-1 


overview, 10-1 




PS:<DN20-1>, 10-1 


, 10-4 


PS:<DN200>, 10-1, 


10-4 


PS:<DNGEN>, 10-1 






in 1 

± u — -L 


PS:<NEW-SYSTEM>, 


10-1 


PS:<SUBSYS>, 10-1 


1 A A 

, ± U — H 


PS:<SYSTEM>, 10-1 


, 10-4 


PTYCON.ATO, 10-1, 


10-8 


RJE, 10-6 




SECDMC.SYS, 10-4 




SYSJOB.RUN, 10-1, 


10-4, 


10-6, 10-10 




SYSTEM.CMD, 10-9 




TERDMC.SYS, 10-4 




Interface , 




operator, 1-5, 1- 


■6 


programmer, 1-5, 


2-4 


terminal user ' s , 


1-6 


Interrupt , 




connect pending, 


3-11 


data available, 3 


-11 


message available 


, 3-11 


Interrupt messages, 




defined, E-3 




limit, 4-5 




receiving, 4-5 




sending, 4-3 




Interrupts , 




clearing, 3-11 




enabling for, 3-10, 3-12 


example of coding 


, 5-6 


processing, 5-6, 


5-7 


setup for, 5-6 




IPCF directory attr 


ibute , 


10-35 




IPCF directory subcommand, 


10-13 
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JFN, 

closing a network, 5-3 
Job status, 

information about, 7-2 



KDP device, 

dumping, 6-21 

error/event logging, 6-24 

in configuration, 9-6 

loading, 6-20 
KMC11, 

in configuration, 9-7 



Line , 

starting a, 6-21 

stopping a, 6-22 

synchronizing a, 6-22 

testing a, 6-21, 6-22 
Line activity, 

logging, 6-15 
Line controller, 

dumping a, 6-21 

loading a, 6-20 

starting a, 6-20 
Line counter types, C-10 

table of, C-10 
Line counters, 

initiate, 6-15 

logging interval for, 
6-16 
Line drivers, 

error/event logging, 6-24 
Line loopback, 

starting, 6-21, 6-22 
Line loopback mode, 

disabling, 6-17 

effect, 6-16 

enabling, 6-16 
Line loopback testing, 6-22, 

10-35 
Line statistics, 

displaying, 6-20 

SYSERR entry for, C-9 
Line status, 

displaying, 6-23 
Line-printer , 

in configuration, 9-7 
Link data base, 3-9 
Link status, 3-10 
Link, See also Logical link 

or Physical link 
Links , 

in configuration, 9-7 

logical, 2-2 

physical, 2-2 



Listing accessible nodes, 

7-2 
Listing directory, 
examples, 8-12 
on remote node, 8-11 
Listing logical node, 7-2 
Listing nodes, 

for file transfer, 8-6 
LOAD CONTROLLER, 6-20 
Load file, 

specifying a, 6-18 
specifying default, 6-14 
specifying secondary, 

6-13 
specifyinq tertiary, 6-13 
LOAD NODE, 6-18 
Loading a line controller, 

6-20 
Loading a node, 6-18 
Loading communications 

front end, 6-13 
Loading nodes, 

specifying default load 

file, 6-14 
specifying load files, 
6-13 
Loading RJE station, 6-13 
Loading the DN20, 6-13, 

6-18 
Local loopback, 6-16 
Local node, 

defined, E-3 
Local NSP, 

defined, E-3 
Local task, 

defined, E-3 
LOCAL-NCP test, 10-26 
LOCAL-NCP-KL-EXAMPLE . CMD 

file, 10-20, 10-26 
LOCAL-NCP-KL-EXAMPLE . TXT 

file, 10-20, 10-26 
LOCAL-NCP-KS-EXAMPLE.CMD 

file, 10-21, 10-30 
LOCAL-NCP-KS-EXAMPLE . TXT 

file, 10-21, 10-34 
LOCAL-NCP.CMD file, 10-20, 

10-28, 10-33 
LOCAL-NCP.CMD file, 

example, 10-29 
Logging interval, 
default, 6-16 
setting, 6-16 
Logging line activity, 6-15 
Logical link, 2-2 
assigned, 3-1 
closing a, 5-3 
creating a, 5-5 
def ined , E-3 
JFN of, 3-23 
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Logical link data, 

reading, 3-12 
Logical link data base, 
3-12 

contents of, 3-12 

created, 3-12 

maintained, 3-12 
Logical link protocols, 1-4 
Logical link status, 3-13 

flag bits, 3-13, 5-2 

reading, 3-13 
Logical links, 

quotas, 3-10 

segment size, 4-1 
Logical node, 

default, 7-2 

defined, E-3 

listing, 7-2 

specifying, 7-2 

vs. physical node, 7-2 
Logical-links , 

in configuration, 9-8 
Login, 

sample programs for 
remote, F-l 
LOOP LINE, 6-22 
Loop-back , 

defined, E-3 
Loopback connector, 6-22, 

10-21 
Loopback mode, 6-21 



/MACY11 

Manual s 

DECSYS 

DECSYS 

6-10 

Messages 

list o 

list o 

6-28 

NETCON 

NETCON 

NFT, 8 

Tkb20, 

Vnp20, 

MO%ABT 1 

3-13 

MO%CDN 1 

3-11 

using , 

MO%CON 1 

3-13 

MO%DAV f 

f unc 

MO%DAV 1 

3-11 



switch, 8-7 
tartup, 

TEM-2020, 6-10 
TEM-2040/50/60, 



f NETCON, 6-27 
f NETCON warning, 

at CTY, 6-26 

fatal error, 6-29 
-16 

G-l 

G-l 
ink status bit, 
, 5-3 
ink status bit, 

3-12 
ink status bit, 

ield for .MOACN 

tion, 3-12 

ink status bit, 



MO%DAV link status 


bit 


(Cont. ) 




using, 3-12 




MO%EOM link status 


bit, 


3-13 




MO%INA field for .1 


VIOACN 


function, 3-12 




MO%INA link status 


bit, 


3-11 




using, 3-12 




MO%INT link status 


bit, 


3-13 




MO%LWC link status 


bit, 


3-13 




MO%SRV link status 


bit, 


3-13 




MO%SYN link status 


bit, 


3-13, 5-2 




MO%WCC link status 


bit, 


3-13 




MO%WFC link status 


bit, 


3-13 




.MOACN function of 


MTOPR, 


2-6, 3-11, 3-12, 5-6 


example, 3-12 




MO%CDN field, 3- 


12 


MO%DAV field, 3- 


12 


MO%INA field, 3- 


12 


.MOCC function of 1 


tfTOPR, 


2-6, 3-23, 5-6 




.MOCIA interrupt control 


value, 3-11 




.MOCLZ function of 


MTOPR, 


2-6, 3-23, 3-25, 5-1, 


5-2 




abort, 5-2 




example, 5-2 




followed by CLOSF, 5-1 


normal close, 5- 


2 


Modem, 




defined, E-3 




.MONCI interrupt control 


value, 3-11 




Monitor call, 




MTOPR, 3-24 




Monitor calls, 




BIN, 2-5, 4-3 




BOOT, 2-5 




BOUT, 2-5, 4-2 




CLOSF, 2-5 




facilities, 2-4 




for receiving data, 4-3 


for sending data 


, 4-2 


functions, 2-5 




GTJFN, 2-3, 2-5, 


3-1 


MTOPR, 2-5, 3-13 


, 3-14, 


3-15, 3-16, 3- 


17, 3-18, 


3-19, 3-20, 3- 


21, 3-22, 


3-23 
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Monitor calls (Cont.) 
network related, 2-5 
NODE, 2-5 

OPENF, 2-5, 3-1, 3-10 
SIBE, 2-5, 4-3 
SIN, 2-5, 3-10, 4-3 
SINR, 2-5, 3-10, 4-3 
SOUT, 2-5, 4-2 
SOUTR, 2-5, 4-2 
Monitor calls used, 1-5 
MOP, 

defined, E-3 
MOP protocol, 

reference document, D-l 
.MORAC function of MTOPR, 

2-6, 3-18 
.MORCN function of MTOPR, 

2-6, 3-20 
.MORDA function of MTOPR, 

2-6, 3-19 
.MORHN function of MTOPR, 

2-6, 3-14 
.MORIM function of MTOPR, 

2-6, 4-5 
.MORIM function of MTOPR, 

example, 4-4 
.MORLS function of MTOPR, 
2-6, 3-13, 5-2, 5-3, 
5-7 
.MORLS function of MTOPR, 

example, 3-13, 5-7 
.MOROD function of MTOPR, 

2-6, 3-21 
.MORPW function of MTOPR, 

2-6, 3-17 
.MORSS function of MTOPR, 

2-6, 3-22 
.MORTN function of MTOPR, 

2-6, 3-15 
.MORUS function of MTOPR, 

2-6, 3-16 
.MOSIM function of MTOPR, 

2-6, 4-4 
.MOSIM function of MTOPR, 

example, 4-4 
MTOPR monitor call, 2-5, 

2-6, 3-11, 3-13, 3-14, 
3-23, 3-24, 5-5 
MTOPR monitor call, 

calling sequence, 3-11, 
3-15, 3-16, 3-17, 3-18, 
3-19, 3-20, 3-21, 3-22, 
3-24, 4-4, 4-5, 5-1, 
5-3 
example, 5-5, 5-6 
functions, 2-6 
Multiplexing, 2-3 



NCP, 

commands to OPR, 6-1 
defined, E-3 
exiting from, 6-20 
NCP command files, 6-24 
NCP command summary, 6-12 
NCP commands, 

accessing, 6-11 
action commands, 6-18 
data base commands, 6-13 
DISABLE EVENT-LOGGING, 

6-24 
DUMP CONTROLLER, 6-21 
DUMP NODE, 6-19 
ENABLE EVENT-LOGGING, 

6-24 
examples, 6-1, 6-3 
EXIT, 6-20 

general categories, 6-11 
INITIATE LOGGING 

LINE-COUNTERS, 6-15 
LOAD CONTROLLER, 6-20 
LOAD NODE, 6-18 
LOOP LINE, 6-22 
miscellaneous, 6-23 
OPR processing, 6-2 
OPR subset, 6-1 
PUSH, 6-24 

REMOTE keyword, 6-11 
responses to, 6-27 
restrictions, 6-3 
RETURN, 6-20 
SET EXECUTOR, 6-23 
SET LOCAL LOOPBACK 

DISABLED, 6-17 
SET LOCAL LOOPBACK 

ENABLED, 6-16 
SET LOGGING-INTERVAL, 

6-16 
SET NODE AUTO-DUMP, 6-18 
SET NODE AUTO-LOAD, 6-17 
SET NODE DUMP-FILE, 6-14 
SET NODE LOAD-FILE, 6-14 
SET NODE PROTOCOL-TYPE, 

6-15 
SET NODE SERVER, 6-13 
SET SECONDARY-LOAD-FILE, 

6-13 
SET STATE LINE 

CABLE-LOOPBACK, 6-22 
SET STATE LINE 

CONTROLLER-LOOPBACK , 

6-21 
SET STATE LINE OFF, 6-22 
SET STATE LINE ON, 6-21 
SET TERTIARY-LOAD-FILE, 

6-13 
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NCP commands (Cont.) 

SHOW COUNTS, 6-3, 6-20 

SHOW EXECUTOR, 6-23 

SHOW QUEUE, 6-19 

SHOW STATUS, 6-1 

SHOW STATUS KNOWN LINES, 

6-23 
SHOW STATUS LINE, 6-23 
SHOW STATUS LOCAL, 6-23 
syntax error messages, 

6-30 
table of, 6-12 
TAKE, 6-24 

TERMINATE logging, 6-16 
NCP module of NETCON, 6-2 
NCP.CMD file, 10-1, 10-6, 

10-7 
NCU, 6-2 

defined, E-3 

OPR/ORION interface, 6-2 
NCU object name, B-l 
.NDCIC function of NODE, 

2-7 
.NDCLP function of NODE. 

2-7 
.NDFLP function of NODE, 

2-7 
.NDGLI function of NODE, 

2-7 
.NDGLN function of NODE, 

2-7 
.NDGNM function of NODE, 

2-7 
.NDGNT function of NODE, 

2-7 
.NDGVR function of NODE, 

2-7 
•NDSIC function of NODE, 

2-7 
.NDSLN function of NODE, 

2-7 
.NDSLP function of NODE, 

2-7 
.NDSNM function of NODE, 

2-7 
.NDSNT function of NODE, 

2-7 
•NDVFY function of NODE, 

2-7 
NETCON, 1-4 
defined, E-4 
examples of responses, 

6-27 
fatal error messages, 

6-29 
SYSERR entry for loading, 

C-2 
types of responses, 6-27 
warning messages, 6-29 



NETCON commands, 1-5 
NETCON messages, 

at operators console, 
6-26 

list of, 6-27 

list of fatal, 6-29, 6-30 

list of warning, 6-28 
NETCON program, 

functions, 6-3, 6-4 

NCP module, 6-2 

NICE module, 6-2 

operator interface, 6-1 

restarting, 6-25, 6-29 

system dependencies, 6-3, 
6-4 
NETCON request queue, 

displaying, 6-19 
NETCON warning messages, 

reporting, 6-29 
NETCON, See also NCP 
NETGEN program, 

commands . 9-5 

defined, 9-5, E-4 
NETGFN, See also 

Configuring DECnet-20 
NETVFY.VER file, 10-20 
Network , 

defined, E-4 
Network access, 2-1 
Network connection, 

aborting a, 5-1, 5-2 

accepting, 3-23 

closing a, 5-1 

normal close, 5-1, 5-2 

rejecting, 3-23 

specifying, 3-5, 3-6 
Network control task, 1-5 
Network dialogue, 

defined, E-4 
Network event and error 

logging, C-l 
Network facilities, 2-4 
Network file access, 8-1 
Network file transfer test, 

10-48 
Network File Transfer, See 

NFT 
Network JFN, 2-3, 3-1 
Network JFN, 

closing a, 5-3 

obtaining a, 3-2 
Network Job File Number, 

See Network JFN 
Network request queue, 

displaying, 6-19 
Network task, 

defined, E-4 
NETWORK-SERVICES-PROTOCOL , 
6-15 
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NFT, 1-1, 1-6 
NFT, 

certifying, 10-48 
defined, E-4 
protocol for, 1-6 
NFT access information 

switches, 8-7 
NFT commands, 

list of, 8-2 
NFT processing mode 

switches, 8-7 
NFT program, 8-1 
and DAP, 8-1 
and NFT.INIT, 8-1, 8-3 
changing access 

information, 8-3 
COPY command, 8-6 
default access 

information, 8-2 
defined, 8-1 
DELETE command, 8-11 
DIRECTORY command, 8-11 
EXIT command, 8-14 
fatal error messages, 

8-16 
file processing modes, 

8-10 
HELP command, 8-14 
INFORMATION command, 8-4, 

8-5 
internal NFT errors, 8-18 
listing accessible nodes, 

8-6 
listing remote directory, 

8-11 
NFT.INIT file example, 

8-3 
responsibilities of, 8-1 
running, 8-2 

SET DEFAULTS command, 8-2 
SUBMIT command, 8-15 
TAKE command, 8-15 
transferring files, 8-6 
TYPE command, 8-15 
warning messages, 8-16 
NFT record length switches, 

8-7 
NFT.INIT file, 8-1, 10-48 
example of, 8-3 
procedure when none, 8-13 
NICE module of NETCON , 6-2 
NICE protocol , 6-2 

defined, E-4 
NICE task, 

and event/error logging, 
6-24 
Node , 

defined, E-4 

in configuration, 9-7 



Node (Cont.) 

SYSERR entry for dumping, 
C-5 

SYSERR entry for loading, 
C-4 
Node identification, 2-4 

name, 2-4 

number, 2-4 
NODE monitor call, 2-5, 2-7 

functions, 2-7 
Node name, 2-4 

changing, 9-16 

defined, E-4 

displaying, 6-23 

in configuration, 9-8 
Node number, 2-4 

changing, 9-16 

defined, E-4 

displaying, 6-23 

in configuration, 9-8 
Node type, 

in configuration, 9-8 
nodename.SYS, 10-4 
nodename.SYS file, 10-1, 
10-7 

use of defined, 9-3 
NRM object name, B-l 
NRT20 program, 

defined, F-l 

initialization routines, 
F-2 

operations, F-2 

source code, F-14 
NRTSRV program, 

defined, F-l 

initialization routines, 
F-4 

operations, F-4 

source code, F-27 

using pseudo-terminals, 
F-4 
NSP, 3-1, 3-23 

code, 2-1 

control of link closing, 
5-1 

data transfer functions, 
4-1, 4-2 

disconnect function, 5-2 

functions, 3-9, 3-10 

interface to monitor, 2-1 

multiplexing, 2-3 

sending node init message, 
6-21 
NSP protocol, 1-4 

defined, E-5 

reference document, D-l 
NULL. TXT file, 10-20 
Number-of-nodes , 

in configuration, 9-9 
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Object descriptor, 

reading the, 3-21 
Object descriptors, 2-4 
OBJECT names, 

FAL, B-l 

NCU, B-l 

NRM, B-l 

TASK, B-l 
Object type, 

reading the, 3-20 
Object types, 2-4, B-l 

table of, B-l 
Obtaining a network JFN, 

example, 5-5 
OPENF monitor call, 2-5, 
3-1, 3-9, 5-5 

example, 5-5, 5-6 

for network connection, 
3-10 

for target task, 3-9 
Opening a network JFN, 3-9 
Operating system, 

displaying, 6-23 
Operator Command Language 

Program, See OPR 
Operator interface, 1-5, 

1-6 
Operator messages, 

NETCON responses, 6-26 

while DECnet is running, 
6-26 
OPR, 

command parser, 1-5 

handling DECnet errors, 
6-30 

interface to NETCON, 6-1 

NCP command parser, 6-2 

NCP command subset, 6-11 

when ORION not running, 
6-32 
OPR command level, 

returning to, 6-20 
OPR initialization failure, 

example of, 6-32 
OPR program, 

defined, E-5 
Optional data, 

reading the, 3-19 
ORION, 

restarting, 6-25 
ORION program, 1-5 

defined, E-5 

handling DECnet errors, 
6-30 

NCP function, 6-2 

not running, 6-32 

restarting, 6-25 
Output destination, 

changing, 7-3, 7-4 



Output destination (Cont. 
specifying, 7-2, 7-4 



Packet, 

defined, E-5 

formation of, 4-1 
PASSWORD, 

reading the, 3-17 
Password receive, 

in configuration, 9-8 
/PASSWORD switch, 8-7 
Password transmit, 

in configuration, 9-8 
Physical link, 2-2 

defined, E-5 
Physical link protocol, 1-3 
Physical links, 

segment size, 4-1 
Physical node, 

defined, E-5 

vs. logical node, 7-2 
PICTUR.TXT file, 10-20 
PLEASE, 

example, 7-3 
prgnam.ERL file, 10-18 
PRINT (TOPS-20 command), 

DESTINATION-NODE switch, 
7-4 
Printer , 

certifying, 10-52 
Printing files, 

specifying output 
destination, 7-4 
Processing mode switches, 
8-7 

/ASCII, 8-7 

/IMAGE, 8-7 

/MACY11, 8-7 
Processing module of NETCON, 

6-2 
Programmer interface, 1-5, 
2-4 

MACRO, 2-4 

monitor calls, 2-4 
Protocol , 

logical link, 1-4 
Protocol error thresholds, 

reporting, 6-24 
Protocols , 

collectively, 1-1 

DAP, 1-6 

defined, E-5 

hardware level, 1-3 

levels, 1-2, 1-3 

NETWORK-SERVICES-PROTOCOL , 
6-15 

NSP, 1-4 
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Protocols (Cont . ) 
physical link, 1-3 
reference documents for, 

D-l 
RSX20F-QUEUED-PROTOCOL, 

6-15 
user level, 1-4 
PS:<DECNET> directory, 
use of defined, 9-2 
PS:<DN20-1> directory, 10-1, 
10-4 
use of defined, 9-2 
PS:<DN200> directory, 10-1, 
10-4 
use of defined, 9-2 
PS:<DNGEN.CMDS> directory, 

use of defined, 9-2 
PS:<DNGEN> directory, 10-1, 
10-4 
use of defined, 9-2 
PS:<NEW-SUBSYS>, 

use when configuring, 
9-10 
PS:<NEW-SUBSYS> directory, 

10-1 
PS: <NEW-SYSTEM>, 

use when configuring, 
9-10 
PS:<NEW-SYSTEM> directory, 

10-1 
PS:<SUBSYS> directory, 10-1, 

10-4, 10-8 
PS:<SYSTEM> directory, 10-1, 

10-4, 10-7, 10-45 
PS: <UETP.DECNET> directory, 

10-20, 10-33 
PS:<UETP.LIB> directory, 

10-20, 10-35, 10-46 
PS: <UETP.RUN> directory, 

10-36 
Pseudo-terminals , 

in NRTSRV program, F-4 
PTYCON.ATO file, 10-1, 10-8 

functions of, 6-7 
PUSH (NCP command) , 6-24 



Queue , 

network request, 6-19 
Quota of open links, 3-10 

configuration, 3-10 

job, 3-10 

system, 3-10 



RDB, 

in configuration, 9-9 



RDB-size, 

in configuration, 9-9 
Reading host name, 3-14 
Reading link status, 3-13 
Reading logical link data, 

3-12 
Reading task name, 3-15 
Reading the account string, 

3-18 
Reading the object 

descriptor, 3-21 
Reading the object type, 

3-20 
Reading the optional data, 

3-19 
Reading the PASSWORD, 3-17 
Reading the segment size, 

3-22 
Reading user name, 3-16 
Reason code for aborting a 

connection, 5-2 
Receiving interrupt 

messages, 4-5 
Record length switches, 8-7 
/FIXED, 8-7 
/VARIABLE, 8-7 
Recording line activity, 
6-15, 6-16 
setting logging interval, 
6-16 
Redefining DECnet data base, 

6-25 
References , 

communications networks, 

D-l 
DAP, D-l 

data communications, D-l 
DDCMP, D-l 
MOP, D-l 
NSP, D-l 
Reject code, 3-25 

sending data with, 3-25 
Reject codes, 3-24 

table of, A-l 
Rejecting a connection, 

3-23, 3-24, 3-25 
Remote file transfer, 8-6 
REMOTE keyword NCP commands, 

6-11 
Remote login, 

sample programs for, F-l 
examples, F-10 
installation, F-6 
special escape characters, 
F-8 
Remote node, 

conditions for accessing, 

6-2 
defined, E-5 
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Remote nodes, 

deleting files from, 8-11 
displaying files from, 

8-15 
listing directory from, 

8-12 
submitting Batch file to, 

8-15 
transferring files 
to/from, 8-6 
Remote NSP, 

defined, E-5 
Remote task, 

defined, E-5 
REMOTE-NCP test, 10-40 

RUN. LOG file, 10-50 
REMOTE-NCP-20-EXAMPLE . CMD 

file, 10-20 
REMOTE-NCP-20-EXAMPLE . TXT 

file, 10-20 
REMOTE-NCP-DN20-EXAMPLE . CMD 

file, 10-20, 10-40 
RLMUTE-NCP-DN20-EXAMPLE . TXT 

file, 10-20, 10-43 
REMOTE-NCP.CMD file, 10-20, 

10-44, 10-46 
Reporting hardware errors, 

6-24 
Reporting NETCON warning 

messages, 6-29 
Reporting protocol error 

thresholds, 6-24 
Reporting unsuccessful 

commands, 6-27 
Restart procedures, 
for NETCON, 6-25 
for ORION, 6-25 
Restarting NETCON, 6-25 

example, 6-25 
Restarting ORION, 6-25 

example, 6-25 
Restrictions , 
displaying line 

statistics, 6-20 
displaying line status, 

6-23 
dumping a node, 6-19 
line logging for 

2040/50/60, 6-15 
loading a node, 6-18 
protocol type, 6-15 
Retrieval of source task 

attributes, 3-7 
RETURN from NCP, 6-20 
Returning to OPR command 

level, 6-20 
Returning to TOPS-20 

command level, 6-20 
RJE option, 1-1 



RJE station, 

certification, 10-51 
certifying card reader, 

10-52 
certifying printer, 10-52 
configuration procedure, 

9-23 
configuring hardware, 

9-26 
loading, 6-13 
RJEVFY.VER file, 10-20 
RSX11S.STB file, 

defined, 9-4 
RSX11S.TSK file, 

defined, 9-4 
RSX20F-QUEUED-PROTOCOL, 

6-15 
RUN. LOG file, 10-38, 10-50 



Sample programs for remote 

login, F-l 
SDB, 

in configuration, 9-9 
SDB-size, 

in configuration, 9-9 
SECDMC.SYS file, 10-4, 10-8 

example, 6-13 
Secondary load file, 

specifying, 6-13 
Segment size, 

of logical links, 4-1 

of physical links, 4-1 

reading the, 3-22 
Segmentation of data, 4-1 
SENDER program, 10-19 
Sending data, 4-1, 4-2 

effect of buffer size, 
4-2 

example, 5-5 

monitor calls, 4-2 

segmenting, 4-1 
Sending interrupt messages, 

4-3 
Server node, 

specifying for load/dump, 
6-13 
Server task, 

defined, E-5 

example of, F-l 
Serverlineid for load/dump, 

specifying, 6-14 
SET NODE DUMP-FILE, 6-14 
SET DEFAULTS, 8-2 

and NFT.INIT, 8-4 

example, 8-4 
SET EXECUTOR, 6-23 
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SET LOCAL LOOPBACK DISABLED, 

6-17 
SET LOCAL LOOPBACK ENABLED, 

6-16 
SET LOCATION, 7-2 

example, 7-3 
SET LOGGING-INTERVAL, 6-16 
SET NODE AUTO-DUMP (NCP 

command) , 6-18 
SET NODE AUTO-LOAD (NCP 

command) , 6-17 
SET NODE LOAD-FILE (NCP 

command) , 6-14 
SET NODE PROTOCOL-TYPE, 

6-15 
SET NODE SERVER, 6-13 
SET SECONDARY-LOAD-FILE, 

6-13 
SET STATE LINE 

CABLE-LOOPBACK (NCP 

command ) , 6-22 
SET STATE LINE 

CONTROLLER-LOOPBACK , 

6-21 
SET STATE LINE OFF, 6-16, 

6-17 
SET STATE LINE OFF (NCP 

command) , 6-22 
SET STATE LINE ON, 6-21 
SET TERTIARY-LOAD-FILE, 

6-13 
Setting executor node, 6-23 
SHOW COUNTS, 6-20 

example, 6-20 
SHOW COUNTS command, 6-3 
SHOW EXECUTOR, 6-23 
SHOW QUEUE, 6-19 

example, 6-19 
SHOW STATUS command, 6-1 
SHOW STATUS KNOWN LINES, 

6-23 
SHOW STATUS LINE, 6-23 
SHOW STATUS LOCAL, 6-23 
SIBE monitor call, 2-5, 4-3 
SIBE monitor call, 
before DEBRK, 4-3 
example, 5-7 
use with interrupt, 4-3 
SIN monitor call, 2-5, 3-10, 

4-3 
SINR monitor call, 2-5, 

3-10 
example, 5-7 
Software versions, 
displaying, 6-23 
Software-ID, 

in configuration, 9-8 
Source node, 
defined, E-5 



Source task, 2-1, 3-1 
attributes, 3-6 
defined, E-5 



unique task name, _. ^, 
Source task coding, 

example of, 5-5 
SOUT monitor call, 2-5, 4-2 

use with SOUTR, 4-2 
SOUTR monitor call, 2-5, 
4-2, 5-5 
example, 5-5 
Specifying a dump file, 

6-19 
Specifying a load file, 

6-18 
Specifying a network 
connection, 3-5 
account, 3-6 
descriptor, 3-5 
host name, 3-5 
object name, 3-5 
object type, 3-5 
password, 3-6 
task name, 3-5 
userdata, 3-6 
userid, 3-6 
Specifying a target task, 

3-3 
Specifying default dump 

file, 6-14 
Specifying default load 

file, 6-14 
Specifying logical node, 

7-2 
Specifying output 

destination, 7-2, 7-4 
Specifying secondary load 

file, 6-13 
Specifying tertiary load 

file, 6-13 
SPRs, 

for NETCON warning 
messages, 6-29 
SRV: , 

descriptor, 3-4 
file specification, 3-3 
network device, 2-2, 3-1 
objectid, 3-3 
task name, 3-4 
Starting a line, 6-21 
Starting a line controller, 

6-20 
Starting error/event 

logging, 6-24 
Starting line loopback, 
6-21, 6-22 
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Startup dialogue DECnet-20 
(2040/50/60), 6-8, 6-9 
Startup dialogue 

DECnet-20(2020) , 6-5, 
6-6 
Startup procedures, 6-4 

DECSYSTEM-2020, 6-4 

DECSYSTEM-2040/50/60, 6-4 
STNRT program, 

defined, F-l 

source code, F-37 
Stopping a line, 6-22 
Stopping error/event 

logging, 6-24 
SUBMIT (NFT command), 8-15 
Submitting Batch file, 

to remote node, 8-15 
Switch , 

/ACCOUNT, 8-7 

/ASCII, 8-7 

/FIXED, 8-7 

/IMAGE, 8-7 

/MACY11 8-7 

/PASSWORD, 8-7 

/USER, 8-7 

/VARIABLE, 8-7 
Switches , 

access information, 8-7 

DESTINATION-NODE, 7-4 

for file transfer, 8-7 

in DELETE (NFT command), 
8-11 

in DIRECTORY (NFT 
command) , 8-12 

in SUBMIT (NFT command), 
8-15 

in TYPE (NFT command) , 
8-15 

NFT COPY command, 8-7 

processing mode, 8-7 

processing mode (NFT) , 
8-9 

record length, 8-7 
Synchronizing a line, 6-22 
Synchronous transmission, 

defined, E-6 
Syntax errors from OPR, 

6-30 
SYSERR entries, C-l 

CHK11 diagnostic, C-8 

common header, C-2 

DUP11 header, C-7 

hardware error, C-6 

line counter types, C-10 

line statistics, 6-15, 
C-9 

NETCON loading, C-2 

node dump, C-5 

node load, C-4 



SYSERR program, 1 

SYS JOB, 

in startup proc 

SYSJOB.RUN file, 
10-6, 10-10 
functions of, 6 

System, 

overview, 1-1 

System dependenci 
BOOT monitor ca 
cache memory, 6 
certification, 

10-51 
configuration , 
configuring RJE 
DUP11, 6-14, 10 
error logging, 
event logging, 
extended addres 
file processing 

8-9 
in line loopbac 
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in Remote-NCP t 
in verification 

10-17 
installation, 1 
installtion, 10 
remote Batch su 

8-15 
REMOTE keyword, 
startup procedu 
verification, 1 
System security, 
guarding agains 

of, F-4 
SYSTEM.CMD file, 
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es , 

11, 2-6 

-8 

10-21, 

9-1 

, 9-22 
-36 
C-l 
C-l 

sing, 6-8 
modes , 

k test, 

est, 10-40 
procedure , 

0-1 

-4 

omission , 

6-11 
res, 6-4 
0-21 

t breach 

10-9 



TAKE (NCP command) , 6-24 
TAKE (NFT command), 8-15 
Target node, 

defined, E-6 

specifying for load/dump, 
6-13 
Target task, 2-2, 3-1 

defined, E-6 

example of, F-l 

file specification, 3-3 

retrieval source task 
attributes, 3-7 

unique task name, 3-4 
Target task coding, 

example of, 5-6, 5-7 
Task , 

remote, E-5 

server, E-5 

source, 3-1, E-5 
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Task (Cont.) 

target, 3-1, E-5 
Task identification, 

generic, 2-3 

unique, 2-4 
Task name, 

reading the, 3-15 
TASK object name, B-l 
Task-to-task capabilities, 
1-1, 1-4 

example of, F-l 
TERDMC.SYS file, 10-4 

10-8 

example, 6-13 
Terminal , 

in configuration, 9-7 
Terminal user, 

accessing DECnet 
information, 7-1 
Terminal user's interface, 

1-6 
Terminal users, 

remote login for, 7-4 

SYSERR program, 7-4 

transferring files, 7-1 
TERMINATE LOGGING 

LINE-COUNTERS, 6-16 
Terminating DDCMP, 6-22 
Tertiary load file, 

specifying, 6-13 
TEST72.CMP file, 10-21 
Testing a line, 6-21, 

6-22 

specifying test data, 
6-22 
Throughput, 

increasing, 3-10 
TKB20 program, 

defined, 9-5, E-6 

error messages, G-l 

warning messages, G-l 
TOPS-20 command level, 

returning to, 6-20 

TOPS-20 commands, 
INFORMATION, 7-2 
relating to DECnet-20, 

7-1 
Transferring files, 8-6 
by terminal user, 7-1 
default destination modes, 

8-10 
giving file processing 

mode, 8-9 
required specifications, 

8-9 
restrictions, 8-10 
Transferring information 

over the network, 4-1 



Transferring information 
over the network, See 
also Sending data 

Transmit-buf f er , 

in configuration, 9-9 

TYPE (NFT command), 8-15 



UETP, 

defined, E-6 

required login directory 

changes, 10-13 
SENDER program, 10-19 
using BATCH log file, 

10-18 
using EXCEPT.LOG file, 

10-18 
using prgnam.ERL file, 

10-18 
using RUN. LOG file, 10-18 
<UETP.LIB> directory, 10-15, 

10-28 
<UETP.RUN>, 10-15 
Unique task identification, 
2-4, 3-15 
monitor supplied, 3-15 
Unsuccessful commands, 

reporting, 6-27 
Up-line dumping, 

defined, E-6 
User data, 

with connect confirm 
message, 3-24 
USER GROUPS directory 
attribute, 10-35 
subcommand, 10-13 
User name, 

reading, 3-16 
User notif icataion of abort, 

5-3 
/USER switch, 8-7 
USERID, 

reading the, 3-16 



/VARIABLE switch, 8-7 
Verification procedure, 
10-12 

defined, E-6 
Verifying DECnet-20, 

flowchart, 10-14 

list of directories for, 
10-20 

list of file for, 10-20 

<SUBSYS>, 10-15 

<UETP.LIB>, 10-15 

<UETP.RUN>, 10-15 
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Verifying DECnet-20 (Cont.) 
using UETP, 10-13 

VF2020.VER file, 10-21 

VNP20 program, 

defined, 9-5, E-6 
error messages, G-l 
warning messages, G-l 



WAIT, 

example of, 5-6 

for interrupts, 5-6 
Waiting for connect, 

example, 5-5 
Warning messages, 

list of NETCON, 6-28 

NFT, 8-16 

TKB20, G-l 

VNP20, G-l 
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